Has anyone implemented a first-order-logic resolution algorithm in Racket by any chance?

There’s a sense in which Racklog is that

Thanks. I can see a unify, but no easy way to extract a resolution procedure: https://github.com/racket/racklog/blob/master/unify.rkt Any clue? (also Racklog is way too fully-featured for my needs currently, but maybe pruning it is easy?)

@mflatt Hi, Matthew. I can’t find table.rktd under https://www.cs.utah.edu/plt/snapshots/. If I want to use one of the last snaphot installers to build packages, which url should I use?

Use the “current” links.

Oh, pkg-build wants “table.rktd”… let me refresh my memory

The “current” link is the right idea: https://www.cs.utah.edu/plt/snapshots/current/installers/table.rktd

Got it. Thank you! I am refreshing my memory as well. I’ve lost a racket file that shows how I used pkg-build…

Question about port flushing and errors, for anyone who might have an opinion…

In the traditional Racket implementation, if there’s an error when you try to flush a buffered TCP output port, then the buffered bytes are retained, and you’ll get an error again if you try to flush again or try to close the port (which implies a flush, unless the close is a force-close via a custodian). In contrast, file and OS-pipe ports drop buffered bytes when a write error occurs. My initial reaction was that file and OS-pipe ports are wrong to discard buffered bytes, but now I think that’s probably the better choice — especially since those ports are registered with a plumber, and so the flush is going to fail yet again after the port-close fails and the program is trying to exit. Does anyone see a problem with making TCP ports behave like file ports? I will make Racket CS match traditional Racket’s behavior, since it currently preserves unsuccessfully flushed bytes in all ports. Also Racket CS registers TCP ports with the current plumber, which sounds nice but probably isn’t really helpful.

It only just now occurs to me to see what the C library thinks, and the C library seems to agree: fflush with buffered bytes to a broken pipe fails only the first time, apparently discarding unsuccessfully flushed bytes so a second fflush succeeds.

I just looked for what Java does, and the documentation does not say.

I didn’t find any such documentation for fflush, either. I checked by writing a program.

I think the relevant Rust code is here; it looks like it doesn’t flush: https://doc.rust-lang.org/src/std/io/buffered.rs.html#488

That gave me the idea to look at miniKanren. Thanks!

So far, I still lean toward dropping bytes on a flush error.