undefined

points

[-]

Agreed... but see my Lisp example in https://news.ycombinator.com/item?id=49593406 for a place where tabs end up unavoidably ambiguous. Because in that `cond` example the tabs look like they're used for indentation, but they're actually being used for alignment, something that falls more under typesetting than under indentation. A smart editor that has read the Lisp code (note that I'm using "read" in its Lisp meaning, i.e. "parsed into a syntax tree") can make those tab characters correctly align the forms the way you'd want them to be aligned for maximum understanding... but really, you would want space characters, not tab characters, in that context.

So even though in most cases those three uses for tabs are independent, in some languages they get muddled. F# is another language where you may want to align text on line two with the middle of line one, e.g. if you write

    let person = { FirstName = "Bill"
                   LastName = "Gates" }

Now, that's considered bad style according to https://learn.microsoft.com/en-us/dotnet/fsharp/style-guide/... — and they're entirely write to recommend against that style — but it's legal syntax. And it's probably why https://learn.microsoft.com/en-us/dotnet/fsharp/style-guide/... forbids tab characters entirely in F# code.

(Those two links point to different anchors in the same document, BTW: the HN link shortening is going to make them look identical until you hover over them).

by fc417fc8024 hours ago|

parent|

[-]

The cond example commits a sin (see my other reply), in the F# example tabs (were they permitted) would introduce no ambiguity if used solely to communicate indentation, and the only change I would make to the F# example were I formatting it myself would be to also align the `=` characters. Actually that supposedly bad style is more or less exactly how I write nix expressions (as a matter of practicality I do not use tabs when writing those FWIW).

by rmunn2 hours ago|

parent|

[-]

I agree that the cond example is committing the sin of trying to align with tabs. I wrote it because I had misunderstood something you were saying. But also, I've personally seen situations like this. I was working in a team whose indentation convention was "one tab character per indent level", and I had written some C# code like this:

    var result = someObject.SomeMethod(param1, param2,
                                       param3, param4);

And then to my horror I noticed that the editor (earlier I said it was VS Code, but thinking back I think it was actually Visual Studio) had produced this monstrosity:

    var result = someObject.SomeMethod(param1, param2,
    <tab><tab><tab><tab><tab><tab><tab>param3, param4);

(Actual number of tabs was different, of course, and I believe it was followed at the end by a space or two, whereas my example happened to line up without needing an extra space character).

I know not to do that. The editor did it anyway, and if I hadn't been paying close attention to whitespace I might not have caught it.

The editor could have been smart enough to parse the code into an AST, notice that param3 and param4 were part of a parameter group, and said "I will use tab characters equal to the indentation of `var result`, then spaces thereafter". It didn't. I had to edit the call to look like this:

    var result = someObject.SomeMethod(
        param1, param2, param3, param4
    );

And then I was safe from the editor trying to align things with tab characters.

If my memory is right about which office I was working in when I saw the editor do that to my code, then it was more than a decade ago, probably around 2010 or 2011. It's possible that the modern version of that editor has improved its handling, and would have correctly aligned param3 with spaces. I haven't checked recently. Maybe at some point I will, and report my findings.