- COFF - www.tuhs.org

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall <dave(a)horsfall.org> > This will probably get me tarred and feathered, but I have a couple of > gripes about C Your points are not about C's semantics, and only sort of about C's syntax; they are more formatting. In fact, it would be really easy to write something to switch a module betweeen your preferred formatting, and 'standard' (for the local value of 'standard') formatting. A minor comment about your first point. I was just reading some old code of mine, and ran across a procedure declaration of the form: foo(string, special) char *string, special; Your preferred form (_without_ changing C's _formal_ syntax) that puts the indirection level with the type has the problems that i) it would make the declaration above potentially confusing (unless one mentally edits the line back to 'classic' C formatting as one reads it; is 'special' a 'char', or a 'pointer to char'; the 'classic' form is quite clear about that); ii) one can only list a single variable per line without changing C's syntax. E.g. (in standard C) if you want to have two pointers declared on one line one would have to say (in standard C): char* ptra, *ptrb; In short, there are good reasons to associate the indirection level with the variable (standard C), and not with the type (yours). Although I gather that you'd probably like to change C's formal syntax, to associate the indirection level with the type, not with the variable. So one could say: char* ptra, ptrb; One could no longer, though, say: char *string, special; One change I would have made to C, in the past, was to add valof/resultis (from BCPL; lacking in C). That's because C macros that return values _have_ to use _only_ expressions (e.g. ((expr0) ? expr1 : expr2)), not more complex code like 'case' (which valof/resultis would let you do). Of course, modern compilers do optimizations that make that a lot less necessary. The thing I would still add to C is condition handling (although I have written assembler packages that added a very efficient one to C without changing the C language; and JTW and someone did a less capable one entirely in C - mine had unwind protects). Explaining why condition handlers are a good thing I don't have the time/energy to do right now, but I can explain it if people want to hear it. Noel

1 month, 3 weeks

1
0
0 0

C with Improvements :-)

by Warren Toomey

I love C; I think it's a great language. But there are things I wish were different in C, and I wish it had less undefined behaviour. I've been having fun designing a language called 'alic' to do the above. I feel proud enough to mention it here. Have a look at the doc which compares it to C, if you are interested: https://github.com/DoctorWkt/alic/blob/main/docs/overview.md Rather than talk about alic, reply with what you like/hate about your favourite language! Cheers, Warren

1 month, 3 weeks

7
8
0 0

Wikipedia anecdotes - LLM generalizations [was On the unreliability of LLM-based search results (was: Listing of early Unix source code from the Computer History Museum)

by Charles H Sauer (he/him)

TUHS->COFF > > It's like Wikipedia. > > No, Wikipedia has (at least historically) human editors who > supposedly have some knowledge of reality and history. > > An LLM response is going to be a series of tokens predicted based on > probabilities from its training data. ... > > Assuming the sources it cites are real works, it seems fine as a > search engine, but the text that it outputs should absolutely not be > thought of as something arrived at by similar means as text produced > by supposedly knowledgeable and well-intentioned humans. > > An LLM can weigh sources, but it has to be taught to do that. A human > can weigh sources, but it has to be taught to do that. Before LLMs, Wikipedia, World Wide Web, ... adages such as "Trust, but verify," and "Inspect what you expect," were appropriate, and still are. Dabbling in editing and creating Wikipedia articles has enforced those notions. A few anecdotes here -- I could cite others. 1. I think my first experience was trying in 2008 to fix what is now at https://en.wikipedia.org/wiki/Vulcan_Gas_Company_(1967%E2%80%931970), because the article had so much erroneous content, and because I had worked/performed at that venue 1969-70. Much of what I did in 2008 was accepted without anyone else verifying. But others broke things/changed things, even renamed the original article and replaced it with an article about a newer club that adopted the name. A few years ago, I tried to make corrections, citing poster images at https://concerts.fandom.com/wiki/Vulcan_Gas_Company. Those changes were vetoed because fandom.com was considered unreliable. I copied the images from fandom to https://technologists.com/VGC/, and then citing those images was then accepted by the editors involved. (The article has been changed dramatically, still is seriously deficient, IMO, but I'm not interested in fixing.) 2. Last year, I created https://en.wikipedia.org/wiki/Hub_City_Movers, citing sources I considered reliable. Citations to images at discogs.com were vetoed as unreliable, based on analogous bias against that site. Partly to see what was possible, I engaged with editors, found citations they found acceptable, and ultimately produced a better article. 3. Later last year, I edited https://en.wikipedia.org/wiki/IBM_AIX to fix obviously erroneous discussion of AIX 1/2/3. Even though I used my own writings as references, the changes were accepted. I still use the Web, Wikipedia, and even LLMs, but cautiously. Charlie -- voice: +1.512.784.7526 e-mail: sauer(a)technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/mas.to: CharlesHSauer

2 months, 1 week

7
11
0 0

Article on bellmac-32 in Spectrum

by Stuff Received

From https://spectrum.ieee.org/bellmac-32-ieee-milestone "The group wrote its own version of Unix, with real-time capabilities to ensure that the new chip design was compatible with industrial automation and similar applications." Would that be in the archives? S

2 months, 1 week

2
1
0 0

Re: [TUHS] Re: Wikipedia anecdotes - LLM generalizations [was On the unreliability of LLM-based search results (was: Listing of early Unix source code from the Computer History Museum)

by jnc＠mercury.lcs.mit.edu

> From: Paul Winalski > Wikipedia quite rightly wants citations for stated facts and this > practice goes a long way to prevent inaccuracies. But I recall one > instance where it actually caused the establishment of a factual error. Not rare; this pattern was the subject of an XKCD strip, "Citogenesis": https://xkcd.com/978/ https://www.explainxkcd.com/wiki/index.php/978:_Citogenesis The latter URL has a very similar story to the one you gave. Noel

2 months, 2 weeks

2
1
0 0

Re: On the unreliability of LLM-based search results

by Alexis

[Redirected from the TUHS list] George Michaelson <ggm(a)algebras.org> writes: >> We're way off topic. Warren should send a kill. > > That said: please don't repeat the "hallucinate" label. It's > self > -aggrandisement. Its deliberate, to foster belief "it's like > thinking" > > It's not a hallucination, it's bad model data and bad constraint > programming. They're not thinking, or dreaming, or demanding not > to be > turned off, or threatening or bullying: They're not Markov > chains > either but they're a damn sight closer to a machine than a mind. Point taken, although i think trying to change that language might be tilting at windwills at this point. Still, i'll try to use alternate phrasing, e.g. "LLMs are known to output nonexistent sources". (Alternative phrasings welcome.) i'd also be interested in an analysis of this: > An artificial intelligence model created by the owner of > ChatGPT has > been caught disobeying human instructions and refusing to shut > itself off, researchers claim. -- https://www.stuff.co.nz/world-news/360701275/openai-software-ignores-explic… Alexis.

2 months, 3 weeks

1
0
0 0

[coff] new history of Netnews

by Nelson H. F. Beebe

List members may be interested in this new article published today: Steven M. Bellovin Netnews: The Origin Story IEEE Annals of the History of Computing 47(1) 7--21 Jan/Mar 2025 https://doi.org/10.1109/MAHC.2024.3420896 ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: https://www.math.utah.edu/~beebe - -------------------------------------------------------------------------------

4 months, 3 weeks

4
3
0 0

[TUHS] What would early alternatives to C have been?

by Douglas McIlroy

Beating a nearly dead horse, I'm shipping this to COFF instead of TUHS to which it responds. > I find > > if (a == b && c == d) > > perfectly reasonable, but > > if ((a == b) && (c == d)) > > to be just silly. Amusing. IT's odd that no one has mentioned the use of spaces for grouping. When the operands of == are simple, I prefer to vary the spacingy spacing. It's less intrusive than extra parentheses and just as clear. if(a==b && c==d) or if( a==b && c==d ) K&R usually flank every infix operator with spaces, unlike classical mathematical usage, where spacing reflects operator precedence. I usually write a*b + c*d, not a * b + c * d, which wantonly flattens the parse tree. Here's an example from K&R, where uniform spacing hampers intelligibility. for (i = 0; s[i] >= '0' && s[i] <= '9'; ++i) n = 10 * n + (s[i] - '0'); The "extra" parens in the second line admirably show the intent of the subtraction. Other groupings are not so well indicated. I would write it like this: for(i=0; s[i]>='0' && s[i]<='9'; ++i) n = 10*n + (s[i]-'0'); (I'll admit that the juxtaposition ]>= is less than perspicuous.) Long identifiers constitute a level of grouping that takes precedence even over multiplication. So I may flank long identifiers with spaces. I suppose then + in a sum of products might deserve double spaces. That's probably a bridge too far, but double spaces after the semicolons in the "for" statement above seem justifiable K&R aren't absolutely rigid about spacing. In the following oddly mixed specimen, the first of three operands in a conjunction is spaced tightly, but the third is not; I guess they feel about != the way I do about long identifiers. i<lim-1 && (c = getchar()) != '\n' && c != EOF The middle conjunct is a challenge. I'd probably squeeze out the spaces. But I might instead try to hold it together with outer parens. Doug

5 months

2
1
0 0

Make your own virtual punchcard

by Douglas McIlroy

Mention of punched cards reminded me of some 1960s trivia. There were two formats for binary code on punched cards for IBM 700-series machines. In "row binary" two 36-bit words filled each of the 12 rows from bottom to top. In "column binary" successive thirds of a word ran downward in each of 3 successive columns. Bob Morris wondered what is the order of the permutation performed in row-to-column conversion. The order of the row-to-column permutation turns out to be 172. There are five cycles of that length plus an oddball of length 4. My souvenir card shows the oddball. If you convert a cycle from row binary to column binary, the output is the same as the input.* Each cycle is also invariant under 180-degree rotation.The 4-cycle is a simple parallelogram. One of the 5-cycles lines up in periodic diagonals. The other cycles show no easily described structure. The images of the two described cycles should be viewed in a fixed-width font. The punches in the 4-cycle are numbered in cyclic order. I keep a few souvenir punched cards. One bears that 4-cycle. * Well, almost the same. The first word on the card contains control information whose layout differs in the two formats. Doug ........................................................................ ........................................................................ ...........................................3............................ ........................................................................ ..............2......................................................... ........................................................................ ........................................................................ .........................................................4.............. ........................................................................ ............................1........................................... ........................................................................ ........................................................................ ..X....X....X....X....X....X....X....X....X....X....X....X....X....X.... ....X....X....X....X....X....X....X....X....X....X....X....X....X....X.. .X....X....X....X....X....X....X....X....X....X....X....X....X....X....X ...X....X....X....X....X....X....X....X....X....X....X....X....X....X... X....X....X....X....X....X....X....X....X....X....X....X....X....X....X. ..X....X....X....X....X....X....X....X....X....X....X....X....X....X.... ....X....X....X....X....X....X....X....X....X....X....X....X....X....X.. .X....X....X....X....X....X....X....X....X....X....X....X....X....X....X ...X....X....X....X....X....X....X....X....X....X....X....X....X....X... X....X....X....X....X....X....X....X....X....X....X....X....X....X....X. ..X....X....X....X....X....X....X....X....X....X....X....X....X....X.... ....X....X....X....X....X....X....X....X....X....X....X....X....X....X..

5 months, 1 week

1
0
0 0

Make your own virtual punchcard

by Charles H Sauer (he/him)

https://boingboing.net/2025/03/10/make-your-own-virtual-punchcard.html [50 years ago today I started working at IBM Yorktown. My boxes of punchcards from graduate work at UT-Austin were enroute with the movers from Austin, to be fed into VM-370 after they arrived. I wish I had kept those boxes as souvenirs.] Charlie -- voice: +1.512.784.7526 e-mail: sauer(a)technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/mas.to: CharlesHSauer

5 months, 1 week

5
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

COFF