HN user

neutrono

30 karma

Groff and LaTeX user. Knows a bit of shell, awk.

Posts0
Comments18
View on HN
No posts found.

In C23 you can use the attribute

    [[nodiscard]]
on functions to mark that the result from function shouldn't be discarded. I think there is also a
    [[reproducible]]
attribute for saying a function doesn't do side effects.
Modern C (2019) 3 years ago

Well, IIRC even in the K&R book, a book which many C programmers admire for it's excellent documentation and prose, and rightly so, there is a specific section mentioning that C's declaration syntax has been castigated.

Next, even if C is not a "high level language", which depend on your definition of "high level language", the perks of a proper module system for low level coding cannot go unmentioned.

- Rust, a language that lives in a somewhat similar abstraction and power space as C, has a module system.

- C++, a language that lives closer to C in features, also now, in C++23 I believe, has a module system, and before that, had namespaces.

On implicit conversions, I think having implicit conversions are hard to get right, and I think that C has them is not a feature, but rather a bug. Languages that have taken some inspirations from C, has chosen usually to do away with implicit conversions, or at the very least, limit their use.

And the array -> pointer in functions, I percieve to be a big mistake, not at the time, perhaps it was not known better ways, but as the years roll by, I think it's a misfeature given the countless exploits that have taken place due to a read past the bounds of an array.

I think C is a good language, but these misfeatures burdens the language in an undue way, and I think a better way to design a language is to be more explicit. Something like Rust's

    unsafe { /* Here be dragons */ }
is better design, in my opinion. I think if you want implicit conversions, there should be an explicit way to declare that you want things to be implicit.

That's just my 2¢

Modern C (2019) 3 years ago

The declaration syntax and the lack of a proper module/namespacing system is also a mistake, but perhaps not as big as the way arrays decays into pointers. Implicit conversions I suppose could also be classified as a mistake.

Maybe something similar to Troff eqn language? Or the formula language in Libreoffice Math? Both of these are a bit more approachable than LaTeX's math mode, IMO.

You can hack it with the \m[<color>] escape in groff:

         \m[blue]int\m[] x
Of course, you would use some kind of pre-processor to make this less of a PITA, but it's not inconceivable.

isn't y = x + x++; undefined behavior in C, because of a lack of a sequence point? If that's true, then it makes sense for no C programmer to know what happens.. I think to fix it you would have to go like: y = x; y = y + x++; I think that would work..

Sadly I don’t know how to futz about with traps, I just haven’t gotten to that point yet in my use of groff.

First I would point you to the manpage, but, we all know that manpages are a mess, so it might not be there. I will however point you, perhaps not /super/ helpful, but alas, I know not of any better solution. If you go to /usr/share/groff/current/tmac/s.tmac and search for «module fn», that should be the code for the footnotes. Aside, the -ms name comes from this, -m means macro, and whatever letter comes after it is the macro set, hence why -man will be called an.tmac in groff source code, or in this case, s.tmac.

I am not sure where documentation is on traps in groff, but I assume it’s buried withing some manpage or info document somewhere. Software is crap, eh? :D

Of course, you could ask in the groff mailing list[1], they are usually pretty helpful in these matters. Which course of action you chose is of course up to you, I will investigate for myself as well to educate myself more on traps.

[1]: mailto:groff@gnu.org

NB: I'm new to HN, so please excuse any formatting errors in this comment.

Well, I've been using groff on and off for a few years, I can give it a shot. Most "macros" as in TeX, are invoked by having the first character of a line be a `.` and then as in TeX, refer to a name. Now, macros in groff are weird. Macros are not delimited by `{}` delimiters as in TeX, but either by having an environment block like so:

    .TS
    .TE
Incidentally, `.TS` and `.TE` is the environment for tbl(1), the pre-processor for tables. Or by invoking another macro, as in this example for headings and paragraphs in the -ms macro set. (The -ms macro set is called as such because that's how you get it into your document, you supply the -ms flag at build time to groff to get the -ms macros). See groff_ms(7) for more information than I will supply here.
    .NH 1
    Some heading here
    .PP
    Start of a paragraph.
Sometimes you want to start a line of input with a period. To do that you just use the character '\&' before the period. The `\&` character is a non printing character, so use it anywhere you want, really. I imagine you want to play with math typography, in that case there is EQN. EQN works by having an environment block, `.EQ` and `.EN` and in that block you type in the EQN mini-language.
    .EQ
    f ( x ) ~=~ x sup {2} - 1
    .EN
EQN does not care about precedence or anything, so use `{}` to delimit expressions. I think there is some kind of EQN document rescued from Bell Labs that tells you about how the language works. Check troff.org for it, or email the mailing list for groff, which is also pretty good for newbie questions, it is not really all that high traffic.

Groff also does pictures, so you can for example create a box with some text in it (it is capable of more, like strokes, macros, color, and I believe rotation[not sure]). To start a picture, `.PS` and `.PE` will do so, and again, a small language as input in that block.

Now, to print anything you should know the design of the original troff system was heavily based on the UNIX philosophy, which means the output you get from running the groff program prints the output to stdout. Just redirect the output to a file to get a PDF or a PS document.

Obviously, there is much I have not covered in this comment, such as macros, registers, and other exciting topics such as refer(1), but this should give you a quick start.