--

  % ramalama run qwen3.5   
   > hi

  Server or container exited. Shutting down client.

  % ramalama run gemma4:e2b
   > hello

  Server or container exited. Shutting down client.

  % ramalama run qwen3.5-9b
  Error: Manifest for qwen3.5-9b:latest was not found in the Ollama registry

And the best thing about the parser combinator approach is that each is just a kind of parser, something like

  type Lexer = ParsecT e ByteString m [Token]

  type Parser = ParsecT e [Token] Expr

It really beats getting to the parentheses-interacting-with-ordering-of-division-operations stage and still having to think "have I already trimmed off the whitespace here or not?"

You wanted 2+1 to yield 3, but instead you get a runtime exception telling you that 2 can't be changed.

It's the whole language, not just the TM code. Other languages have no way of opting out of the TM code, whereas Haskell does.

By withholding calculators, did your teachers prove you understood the fundamentals? Or did they actively hamper your ability to compete mathematically?

>> "a term can have only one type... Due to this law, types cannot contain themselves"

> types are not sets and sets are not types therefore it makes no sense to link these two statements/judgements in the way you are linking them

In one system, a set can contain itself, in another system it can't.

So it doesn't really make sense to ask 'can it?'

If you allow sets to contain themselves, you also have to talk about sets which do not contain themselves, which yields Russell's paradox.

If you disallow sets (or types) from containing themselves then you can't construct Russell's paradox, which is why it follows.

2020 - LinkedIn Sued For Spying on Clipboard Data After iOS 14 Exposes Its App:

https://wccftech.com/linkedin-sued-for-spying-on-clipboard-d...

2013 - LinkedIn MITM attacks your iPhone to read your mail:

https://www.troyhunt.com/disassembling-privacy-implications-...

2012/2016 - Data breach of 164.6 million accounts:

https://haveibeenpwned.com/breach/LinkedIn

According to haveibeenpwned.com, my email & password were leaked in both the 'May 2012' and 'April 2021' LinkedIn incidents.

If websites could charge 5.99/month, they would.

If a website was charging 5.99/month, they would not stop spying on you.

-> [Endor Labs] https://www.endorlabs.com/learn/teampcp-isnt-done

-> On March 24, 2026, Endor Labs identified that litellm versions 1.82.7 and 1.82.8 on PyPI contain malicious code not present in the upstream GitHub repository. litellm is a widely used open source library with over 95 million month downloads. It lets developers route requests across LLM providers through a single API.

If I write this Java:

  pair.map((a, b) -> Foo.merge(a, b));

  pair.map(Foo::merge);

  ...

  :<|> collectionsServer compactor env registry
  :<|> queryServer qp sp struc registry warcFileReader logger
  :<|> indexationServer fetcher indexer

  ...

So lets try making the the arguments of just the collections server explicit. (It will take me too long to try to do them all.)

You can 'list' collections, 'delete' a collection, merge collectionA into collectionB, or get the directory where the collections live. So the input (the lambda term(s) we're trying to make explicit) can be () or (collectionName) or (collectionNameA, collectionNameB) or ().

In order to put these lambda terms explicitly into the source code, we need to add four places to put them, by replacing collectionsServer with the routes that it serves:

  ...

  :<|> (       listCollections registry
         :<|> (\collectionName -> deleteCollection env registry collectionName)
         :<|> (\collectionName1 collectionName2 -> mergeInto compactor collectionName1 collectionName2)
         :<|>  getCollectionDir env ) 
  :<|> queryServer qp sp struc registry warcFileReader logger
  :<|> indexationServer fetcher indexer

  ...

I read the 'Partial Functional Relationships' section. There's nothing special there. It's just structs with nulls.

> Polluting every type with it I think you're reacting to the pollution of the syntax. Hoare already polluted the semantics: Every type can be null. You can't even model a NonNull because NonNull itself can be null.

* It's the same referent as all the other things you don't have. Your struct has a Spouse, why does it not also have a RivieraChateau, a SantaClaus, BankAccountInSwissFrancs. If you can answer why you left those out, you know why to leave out Spouse.

* Why stick to 0-1 Spouses. As soon as you do that you're gonna need n Spouses, where some of them will have an ex- flag set, married from&to timestamps.

> Is your point here that every pointer type for which this can be the case should include an explicitly typed null value?

* It shouldn't make a difference whether it's a pointer or a reference or a value or a class. If you believe null is one of the Integers, you should also believe that null is one of the ints. Why should your domain change to accommodate C idioms.

I took major exception to this. The real world doesn't have non-things, and references do not demand to refer to non-things.

If your domain does actually have the concept of null, just make a type for it. Then you won't accidentally use a 6 or a "foo" where a null was demanded.

If you x.getY(), is that a member access, a computed value, or a network fetch? Will it lazy-instantiate a log4j singleton and start spamming my IDE with red text? I refuse the OO dogma that x should be a black box, and I as the programmer on the outside should not concern myself with its implementation details.

Onto TFA's parser example:

  typedef struct Parser {
      // fields
  } Parser;

  Statement  parser_parse_statement(Parser *p);
  Expression parser_parse_expression(Parser *p);
  void       parser_expect(Parser *p, const char *message);
  void       parser_next(Parser *p);
  TokenKind  parser_current(const Parser *p);

Correct. You can write OO in any language, and this parser hides machinery and is acting like a class, not a value. Look at those voids - those methods either do nothing, or they modify the insides of the parser. I certainly can't combine them like I could with values, e.g.:

  Parser *p = choice (parse_statement, parse_expression);

It is much easier to parse without hidden machinery. Combine them like values, e.g.:

  Parser parser_block   = many (parse_statement);
  Parser parser_sum     = seperateWith (parser_plus, parser_product)
  Parser parser_product = separateWith (parser_times, parser_value)
  Parser parser_value   = choice (parser_literal, parser_variable)

Then just unhide the internal cursor or success/failure state (or whatever other machinery is hidden in there) and pass them in as values:

  (result, remainder_string) = run_parser (parser_block, input_string);

A map of what ?