I went down the rabbit hole last night, and found some great resources on variational selectors. Thanks for the inspiration, I added a demo of this to the site as well!
I also have a corresponding blog post here, where I use this capability to embed custom JSX types as an alternative way to express 'concatenative' higher-kinded pipelines: https://code.lol/post/programming/jsx-hkt/
I've had similar issues with conversation memory in ChatGPT, whereby it will reference data in long-deleted conversations, independent of my settings or my having explicitly deleted stored memories.
The only fix has been to completely turn memory off and have it be given zero prior context - which is best, I don't want random prior unrelated conversations "polluting" future ones.
I don't understand the engineering rationale either, aside from the ethos of "move fast and break people"
This is a LLM directly, purposefully lying, i.e. telling a user something it knows not to be true. This seems like a cut-and-dry Trust & Safety violation to me.
It seems the LLM is given conflicting instructions:
1. Don't reference memory without explicit instructions
2. (but) such memory is inexplicably included in the context, so it will inevitably inform the generation
3. Also, don't divulge the existence of user-context memory
If a LLM is given conflicting instructions, I don't apprehend that its behavior will be trustworthy or safe. Much has been written on this.
Let's stop anthropomorphizing these tools. They're not "purposefully lying", or "know" anything to be true.
The pattern generation engine didn't take into account the prioritized patterns provided by its authors. The tool recognized this pattern in its output and generated patterns that can be interpreted as acknowledgement and correction. Whether this can be considered a failure, let alone a "Trust & Safety violation", is a matter of perspective.
IMHO the terms are fine, even if applied to much dumber systems, and most people will and do use the terms that way colloquially so there's no point fighting it. A Roomba can "know" where the table is. An automated voice recording or a written sign can "lie" to you. One could argue the lying is only done by the creator of the recording/sign - but then what about a customer service worker who is instructed to lie to customers by their employer? I think both the worker and employer could be said to be lying.
It's a bit of a hack, though - if you incorrectly implement myFunc so that, say, it returns a string even when x is true, it can violate the overloading assertions without any error or warning.
> I also avoid technologies where the code I write is different from the code being executed.
Not to be snarky, but as opposed to writing assembly? Where do you draw the line if you don't allow TypeScript (which is, with limited exceptions, only type erasure unless you specifically request polyfill), but allow other forms of compilation? Would you define JVM bytecode or IR as messy-looking junk code?
It's hard to see how a principled line could be drawn here.
If I had the mental capacity and time to write it in assembly, then that would be better. But then probably still not worth it due to added maintenance challenges. I guess it's really about mental capacity and time.
The difference in the amount of value provided by a JS engine abstracting away from binary code vs TS transpiling to JavaScript is massive. The TS transpiler's value is extremely marginal by comparison, especially when considering the amount of trouble it brings.
Also, I'm familiar enough with the V8 engine and other ECMAScript-compliant engines that I have a good sense of how my code is being executed on there. I don't have to worry about TypeScript dropping support for a specific configuration setting in tsconfig and then having to spend hours trying to figure out why my code isn't working anymore.
However, I wouldn't define bruijn as being caramelized just yet. Personally, I view as syntactic sugar only syntax that's expanded to the target language by the parser/compiler. In bruijn's case, there is barely any of such syntax sugar aside of number/string/char encodings. Everything else is part of the infix/prefix/mixfix standard library definitions which get substituted as part of the translation to LC.
Is there any hope for a "hashlife" style cache for a TC language? My understanding is that hashlife exploits spatial locality / "causation speed" in GoL, which isn't available in LC because of beta reduction. Thoughts?
I don't know any quadtree/lowlevel encoding of LC that could be memoized like that. Though you could, for example, cache the reduction of any term by hash and substitute the matching hashes with its nf. This doesn't really work for lazy reducers or when you do not reduce strongly. And, of course (same as hashlife), this would use a lot of memory. With a lot more possibilities than GoL per "entity" (NxN grid vs variables/applications/abstractions), there will also be a lot more hash misses.
There's also graph encodings like interaction nets, which have entirely local reduction behavior. Compared to de Bruijn indices, bindings are represented by edges, which makes them more applicable to hash consing. I once spent some time trying to add this kind of memoization but there are some further challenges involved, unfortunately.
Recently, LeetCode has begun hiding instructions (using css) in their competitions to use particular unique variable names like 'dexolarniv' - and anyone using such a variable name in their submission gets summarily banned.
In their implementation, the hidden prompt does show up on copy/paste - however I tested this method, and the LLM (i.e. ChatGPT) does still follow the Unicode-hidden instruction and uses 'dexolarniv' in the code returned! So I think this is (right now) a viable invisible injection strategy.
No language is going to replace mainstream languages if it comes with minimal libraries. PS and similar langs are nice efforts but unfortunately pointless.
If folks are interested in this sort of thing, but want to play around with higher order building blocks, http://hkt.code.lol may be worth checking out.
In addition to type-level analogues of your normal Lodash-esque functions, it includes a suite of type-level parser combinator utilities and is built on higher-kinded type abstractions.
reply