deredede

> Modular implicits have been shelved indefinitely from what I understand, if that's what you're referring to.

They have not — people are still working on it. There's been a paper at the OCaml Workshop at ICFP this year, and a PR on the OCaml repo. The student who worked on this is now starting a PhD on modular implicits in the lab that created OCaml.

It was, but then they changed their mind apparently

https://discuss.ocaml.org/t/owl-project-restructured/14226

Too early to tell what it will lead to.

> Is Raven the successor to Owl?

That's what I am wondering too (especially with the name), but I couldn't find a reference to Owl in the repo.

The lack of ad-hoc polymorphism has to be there somewhere as well.

This looks interesting, it's great to see more machine learning efforts in typed languages.

I'm a bit surprised to see no mention of Owl (https://github.com/owlbarn/owl an older project for scientific computing in OCaml that was resurrected recently), I wonder how they compare.

The Raven README mentions:

> We prioritize developer experience and seamless integration.

so maybe that's one difference — I used Owl on a course project about a decade ago, and while it got the job done, I remember the experience being rather painful compared to Numpy (even though I was more experienced with OCaml than with Python at the time).

> Afraid to close the page because they wont find it in their history or bookmarks? Is this more an issue with bookmarks and history not being as useful as they could be?

I think tabs are just the better user interface.

It's not that I'm afraid I won't find the page in my history and bookmarks, it's that I don't want to have to do that because it's painful. History is full of irrelevant pages. Bookmarks make me lose my flow constantly wondering if I should bookmark a page or it's not needed (and in which directory!).

Tabs have a very simple workflow with low cognitive overhead. Everything is preserved by default (middle click/ctrl click is my default click in a browser), unless I'm clearly in a linear workflow where I don't want to keep the page (left click). Self-organizing due to the way they open, but very easy to manually reorder (or close) if needed. Kept in memory so going back to a (recent) tab is instantaneous.

They just... get out of the way and let me work. Tabs make browsing feel like one continuous task, where history/bookmarks feel like constant interruptions.

Code in this "named-pipeline" style is already self-documenting: using the same variable name makes it clear that we are dealing with a pipeline/chain. Using more descriptive names for the intermediate steps hides this, making each line more readable (and even then you're likely to end up with `dataStripped = data.map(&:strip)`) at the cost of making the block as a whole less readable.

Those are equivalent, I think. If you can replace an expression by its value, any two expressions with the same value are indistinguishable (and conversely a value is an expression which is its own value).

Machine learning is not magic -- no algorithm, machine learning or otherwise, will be able to treat an arbitrary-length sequence in constant time.

The actual problem is also more complex than fixed word widths due to hyphenation and justification - from what I recall, Knuth's paper (IIRC there's two and the second one is the one to read) on TeX's layout gives a good overview of the problem and an algorithm that's still state of the art. I think the Typst people might have a blog post about their modern take on it, but I'm not sure.

Zig's comptime is not macros, it's staged programming / multi-stage programming.

You typically don't represent that information in the type of the object itself but rather as separate information for the type of the values (ie fields). So maybe it's "a list, and also the values are lists" or maybe it's "a list, and also the first value is a string, and the other values are integers"... and maybe it's "a list, and the values are strings, and also it has a field named 'foo' that's an integer for some reason".

You can still have the same information (depending on the actual system), just represented differently - parametric polymorphism is a bit too rigid here because not everything fits neatly into generic schemas.

In many cases Earley parsers are linear though.

Do yourself a favor and go increase the text size (not zoom!) in your browser's (if not OS's) settings.

While sub-optimal, your first example is probably fine to send and I'd expect to be simplified early during query planning at a negligible cost to the database server.

What you shouldn't send is queries like:

    SELECT \* FROM users
    WHERE ($1 IS NULL OR id = $1)
        AND ($2 IS NULL OR username = $2)
        AND ($3 IS NULL OR age > $3)
        AND ($4 IS NULL OR age < $4)

because now the database (probably) doesn't know the value of the parameters during planning and needs to consider all possibilities.

This is the take I thought I'd have, but in the last example, the guesser model reaches the correct conclusion using a different reasoning than the clue giver model.

The clue giver justifies the link of Paper and Log as "written records", and between Paper and Line as "lines of text". But the guesser model connects Paper and Log because "paper is made from logs" (reaching the conclusion through a different meaning of Log), and connects Paper and Line because "'lined paper' is a common type of paper".

Similarly, in the first example, the clue giver connects Monster and Lion because lions are "often depicted as a mythical beast or monster in legends" (a tenuous connection if you ask me), whereas the guesser model thought about King because of King Kong (which I also prefer to Lion).

Parametricity is about behavior, not code. A function parametric in a variable should bevave identically for all values of the variable. If one instance of a C++ template fails to compile and another instance of the same template does compile it is a stretch to say they behave identically, even though they use the same code.

You don't keep track of it as extra state - positions are already processed in increasing order of shortest mate, you stop once you hit 50.

> I think messenger apps generally nudge us that way - e.g. setting the name of the chat usually sets it for everyone.

That's a good point - maybe it's actually email that warped my mind.

> I'll read them in one order on receipt and in a different order when looking back

Also a good point, I was thinking more about business communication where the date the letter is received matters. Thinking back on it, I think the main difference is that the messenger apps might happily reorder message before (or while) I read them. And if only one order is to be available, the one of the most use to me for an instant messaging app is the one I received the messages in, but I get how for other use cases it would be different.

Messenger apps don't claim that this history should be global and consistent. The order in which messages were sent and received by my device is a perfectly fine (and I'd say intuitive) history. It is the order people (and their records, if they have some) would have had in mind in the old time.

I take a different conclusion from the way people look at physical objects: since your device (or even my other device) is a different physical object than my device, I'd be wholly unsurprised to find a different order there.

> Yes a client may be out of date and therefore show something different, but once it becomes up to date it should be showing the same state even if that means amending history. Why? Because the humans reading it will be confused otherwise! An app getting more data is something we intuitively understand, but if my client shows something and yours shows something else, we will conclude different meanings from it.

That's interesting because I have the complete opposite take and would hard disagree with this. I intuitively understand that if we both write messages at the same time, we will see them in different order. Snail mail has worked this way for centuries, and I very much prefer this to an app silently altering the content as time goes. It is confusing when it happens under my eyes (something moved at the top of the screen while I was reading the bottom, what was it?) and easily leads to missed messages especially in group conversations (my buddy sent a message with a poor connection at 11am, it is retried and sent at 2pm and appears before the lengthy discussion others had at noon).

I assume this is tongue-in-cheek, but I don't think the comparison works at all.

I spend maybe 1% of my working hours (being generous) using `ls` and something like 50% (likely more) using my editor.

If there is some alternative to `ls` that makes my `ls` workflows 2x faster, my productivity increases by 0.5%. If I use a sub-optimal editor that makes my workflow 2x slower, I lose 25% of my productivity.

When I need to login to a remote box, I am also very likely to need to use `ls` since I am less familiar than on my own machine, whereas I am unlikely to do any sort of heavy development work (typically I just need to edit a couple configuration files, or do some git operations).

> What this means is that all nominal variants and records are really just nominal wrappers over structural variants or records.

If you have both nominal types and structural types in your language, you can already do this, while keeping the ability to be nominal only or structural only when you want.

In the following OCaml code variant inference in pattern matching is not automatic (although the compiler will warn you about the missing cases, which helps you figuring what to write), but the types do get refined in the corresponding branch.

    type 'a tree =
      Tree of
        [ `Empty
        | `Branch of ('a tree * 'a * 'a tree)
          (* Unfortunately, inline records are not supported here,
             so you have to use tuples, objects, or a mutually recursive record
             type. *)
        ]
      [@@unboxed]

    (* You can give aliases to subsets of constructors *)
    type 'a branch =
      [ `Branch of ('a tree * 'a * 'a tree) ]
    
    let f (x : 'a branch) = ()
    
    let f x =
      match x with
      | Tree `Empty -> ()
      (* You need to be explicit about the cases you want to handle. This pattern
         could also be written `Tree (#branch as rest)`. *)
      | Tree (`Branch _ as rest) -> f rest

The one feature I'd really like in this space would be the ability to refer to a subset of the constructors of a nominal types as if it was a (restricted) polymorphic variant that could only be recombined with another subset of constructors of the same nominal type. It would allow some of the power of polymorphic variants without losing the efficient representation allowed by nominal types knowing the possible variants ahead of time.

> Bug givers (the evil version of a bug chaser) deserve felonies.

I agree; I think that knowingly transmitting any communicable disease deserves a felony, but I don't think that HIV deserves to be singled out when all other such diseases are a misdemeanor. Hepatitis and herpes (oral herpes is very common; genital herpes much less so) are also known to cause mental issues and to increase suicide risk, if that's your criterion.

(Poppers are recreational drugs, I'm not aware of any link with AIDS except that they were thought to be a possible cause in the '80s. Were you thinking of prep?)

I was surprised at the claim that intentionally giving someone AIDS would be decriminalized, so I looked it up. The AIDS bill you seem to refer to (SB 239) lowers penalties from a felony to a misdemeanor (so it is still a crime), bringing it in line with other sexually transmitted diseases. The argument is that we now have good enough treatment for HIV that there is no reason for the punishment to be harsher than for exposing someone to hepatitis or herpes, which I think is sound.

It's an old feature. You have to open the door manually, and the new trains (especially on automated lines) don't allow this.

This was updated in 2022 but was indeed written and originally published in 2013.

Not independently invented again. Lionel is fully aware of the level tracking in the OCaml type-checker; in fact the OP is cited in the Simple-sub paper (section 3.5.1, page 15).

I think you remember wrong. Rust is moving towards using a datalog engine, but for lifetime resolution (the project is called Polonius), not for type checking. Datalog engines have some similarities with SMT solvers so this might be what you're thinking of.

Having one set of developers write the code and another set of developers write tests from the same specification without reading the code is probably the most effective ways to use tests for high software quality and is typically required by certification bodies e.g. for avionics.

There is an (apocryphal) anecdote about the person next to Picasso at a corrida being amazed seing him sketch a bullfight in seconds, to which Picasso allegedly replied "Seconds? It took me my whole life to be able to draw this."

I'd wager your wife has much more drawing experience than you. If you keep practicing, you'll be able to draw faster and faster.

I am not an expert in either tag systems (or `find`), but this seems right. Using backreferences to handle copies sounds right (it does add expressive power to regular expressions but does not give Turing completeness, afaik).

I think your first example is missing the "any word of length < 2 is a halting word" condition but it is present in your second example.