Yes you can - that's just a existential type. I'm not sure what the syntax would be, but it could be somthing like:

  List (exists a : {x=int, ...'a})

  List ((forall a : {x=int, ...'a} -> b) -> b)

  $ units
  You have: 25m2 / 2tau(700km)^2
  You want: /billion
    * 0.0040600751
    / 246.30086

Yes, with the obvious possible exception of trivial/degenerate cases like "i++; j--;" in C or "This is a cat. That is a dog." in English.

> and every line break represents a semantic clause or sentence gap.

Specifically, it represents a maximally coarse semantic gap, drilling as shallowly down into subclauses as possible/practical.

> wrap/line break [can happen at ...] also a semantically valid intra-word line break.

Preferably only if that word would already be alone on its overly-long line. Eg:

  # bad, breaks subordinate clause before superordinate
  That sounds supercalifragilistic-
    expialidocious.
  
  # semantically valid, but ugly (a pathological case)
  That sounds
    supercalifragilisticexpialidocious.
  
  # vertically larger, but probably fine
  # (unless you're feeling incunabulum-y[0])
  That sounds
    supercalifragilistic-
    expialidocious.

I've yet to see any evidence that really pathological cases exist. (As opposed to "I'm lazy and can't be arsed" cases, which I'm fairly explicitly not disputing.)

0: http://code.jsoftware.com/wiki/Essays/Incunabulum

Poor phrasing; 20 characters was meant as a example of a limit that is pathologically short.

So would I, but...

> if a single semantic unit (be that a word, a clause, or whatever else) extends beyond, say, 80 characters, we keep it on the same line and let the editor/file viewer handle wrapping.

...the editor can't do that because it doesn't understand the semantics.

> that wrapping based on semantics is an orthogonal concept to hard and soft wrapping

Yes, that's why I've been saying "hard and/or soft [but in either case nonsemantic] wrapping".

> > > With semantic wrapping you put each sentence (or similar) on a new line [...] But if that sentence runs over e.g. 80 characters, [then...]

... You don't need to fall back on non-semantic wrapping, you can just just keep breaking it up into smaller and smaller semantically-meaningful pieces.

(You have to do that 'hard'-ly because the editor doesn't understand the semantics, but that's not "decid[ing] whether you're going to hard wrap or soft wrap", it's being forced to hard wrap as a implementation detail because that's what results in correct wrapping.)

It might not be worth the effort to do that, but you're never forced not to (given not-pathologically-short line length limits like 20 characters).

I have no idea what the semantics of that word are, which is information that is required in order to properly semantically wrap it. (Inherently, since conveying such semantics is one of the major pointer of semantic wrapping.)

However, you included embedded control characters (C2 AD aka 'SOFT HYPHEN'; below replaced with '-') that encode less semantic information than is necessary for proper semantic wrapping, but not none:

Lopado-temacho-selacho-galeo-kranio-leipsano-drim-hypo-trimmato-silphio-karabo-melito-katakechy-meno-kichl-epi-kossypho-phatto-perister-alektryon-opte-kephallio-kigklo-peleio-lagoio-siraio-baphe-tragano-pterygon.

Web browsers use that information to do poor-quality semantic wrapping automatically - actual hard or soft[0] wrapping would produce something like:

  Lopadotemachoselachogaleokranioleipsanod-
  rimhypotrimmatosilphiokarabomelitokatake-
  chymenokichlepikossyphophattoperisterale-
  ktryonoptekephalliokigklopeleiolagoiosir-
  aiobaphetraganopterygon.

Lopado-temacho-selacho-galeo-kranio-leipsano-d[BREAK]rim-hypo-trimmato-silphio-karabo-melito-katake[BREAK]chy-meno-kichl-epi-kossypho-phatto-perister-ale[BREAK]ktryon-opte-kephallio-kigklo-peleio-lagoio-sir[BREAK]aio-baphe-tragano-pterygon.

The fact that you included soft hyphens rather concedes the point that hard and soft[0] wrapping is incorrect[1].

0: Or rather, non-semantic, which is what we're actually arguing over. Technically, semantic wrapping is a subset of hard wrapping, but it's a specific subset that isn't what is expressed by just saying "hard wrapping". Kind of like how birds aren't what anyone means when they just say "dinosaurs".

1: Granted, to be fair, a lot of the time we just don't care. But (contra your original comment) we never need to resort to non-semantic wrapping; we just sometimes (often) decide to be lazy because it doesn't matter.

  > But if that sentence runs over e.g. 80 characters,
  >  you still need to decide
  >  whether you're going to hard wrap or soft wrap that sentence.

You mean this article?

https://vitalik.eth.limo/general/2021/06/18/verkle.html

> Verkle trees are still a new idea; they were first introduced by John Kuszmaul in this paper from 2018[link to [0]],

0: https://math.mit.edu/research/highschool/primes/materials/20...

"antimemetics".

Antimimetics is also a thing, and might be interesting to read about, but it's not the same thing.

> > A much simpler[-and-more-nitpickable] version

Myhill uses a parlor trick to make his version continuously differentiable. It's a pretty good parlor trick, but it doesn't have much to do with computability.

Pedantically, it's that the bumps grow exponentially narrower.

IIUC, a simpler (but more nitpickable) version would be f'(n+1/y) = [the fraction of n-state Turing machines that halt within y steps] (for positive integers n, and 0 elsewhere); then f is the integral of f'. The value of f(x) can be approximated arbitrarily well by running every floor(x)-state Turing machine for a large finite number of steps[2], but f'(x) is equal to Chaitin's constant[0] for n-state Turing machines over a strictly-positive-length[1] subinterval of [n,n+1).

A much simpler version is f'(x) = {-1 if x<0; +1 if x>0; Chaitin's constant if x=0}. f(x) = abs(x).

Basically, this isn't even a parlor trick. It's a nothing burger, disguised as something by means of a parlor trick.

0: https://en.wikipedia.org/wiki/Chaitin%27s_constant

1: And so strictly-containing-rational-numbers, although predicting which rational numbers is nontrivial.

2: The rounding error from assuming all machines that halt after y steps actually run forever scales as O(1/y) in the worst case.

No, the number of floats between 0 and 1 is (approximately) the same as the number of floats between 1 and positive infinity. And this is the correct way for it work: 1/x has roughly the same range and precision as x, so you don't need (as many) stupid obfuscatory algebraic transforms in your formulas to keep your intermediate values from over- or under-flowing.

This can be done by composing a prefix code with a suffix code:

    A   0
    B  01
    C  11
  a A  0
  b BA 010
  c BB 0101
  d BC 0111
  e C  11
  {a=0,b=010,c=0101,d=0111,e=11}

And it's neither prefix nor suffix itself, since a=0 and b=010. In fact, it can't in general be decoded incrementally at all, in either direction, since "cee...ee?" vs "bee...ee?" and "?cc...cca" vs "?cc...ccb" both depend on unbounded lookahead to distinguish a single symbol.

I'm not sure the optimality holds for any composition of a in-isolation-optimal prefix code with a in-isolation-optimal suffix code, but it did work for the most trivial cases (other than the degenerate 1-to-1 code) I could come up with.

Try:

  $ A='https://web.archive.org/web/20240701123410'
  $ B='https://staging.cohostcdn.org/attachment'
  $ C='11357255-b6b9-4a57-98eb-823776a4a828'
  $ D='KowloonWalledCityGrandPanorama.jpg'
  $ wget "$A/$B/$C/$D"