>though maybe there's a path forward to give a variable a sort of "de-hint" in that in can be everything BUT this type
I think this is called a negation type, and it acts like a logical NOT operator. I'd like it too, and I hear that it works well with union types (logical OR) and intersection types (logical AND) for specifying types precisely in a readable way.
If your data format is so complicated that all commonly used implementations are not compliant with your spec, maybe it's a problem with the data-format.
Every single implementation people actually use seems to be a messy mix of yaml 1.1 and 1.2....
Maybe if the yaml project wants to consider this fixed, they should have written some correct reference parsers themselves for any languages in need, and encouraged their use.
I noted this in reply to the comment above, but: the YAML 1.2 spec doesn't actually mandate that parsers use the Core Schema. They left it as a recommendation. So I don't consider it to be "fixed" at all.
I would not say it "fixed" the problem. It removed the _recommendation_ for parser implementations to use the regex `y|Y|yes|Yes|YES|n|N|no|No|NO|true|True|TRUE|false|False|FALSE|on|On|ON|off|Off|OFF` for parsing scalars as bools, it changed the _canonical_ presentation of bools from `y|n` to `true|false`, and it introduced the "schema" concept. It also introduced and recommended the use of the Core Schema, which uses `true|True|TRUE|false|False|FALSE` as the regex for inferring bools from scalars. But unsurprisingly, since using this schema is only a recommendation and not a requirement, many implementations elected to keep their backwards-compatible implementations that use the original regex.
the recommendation was what caused the norway problem. it now strongly recommends not to do this, and it says that a Yaml parser should use the core schema unless instructed otherwise. going against the recommendation while saying that you're yaml 1.2 compliant feels like an issue that should be raised with the parser to me. I've never run into this issue in practice though.
is there a parser that says that it's Yaml 1.2 compliant that uses that regex? I don't know of one.
I tried the playground and got a strange response. I asked for a regex pattern, and the model gave itself a little game-plan, then it wrote the pattern and started to write tests for it. But it never stopped writing tests. It continued to write tests of increasing size until I guess it reached a context limit and the answer was canceled. Also, for each test it wrote, it added a comment about if the test should pass or fail, but after about the 30th test, it started giving the wrong answer for those too, saying that a test should fail when actually it should pass if the pattern is correct. And after about the 120th test, the tests started to not even make sense anymore. They were just nonsense characters until the answer got cut off.
The pattern it made was also wrong, but I think the first issue is more interesting.
FWIW, I remember regular models doing this not that long ago, sometimes getting stuck in something like an infinite loop where they keep producing output that is only a slight variation on previous output.
if you shrink the context window on most models you'll get this type of behaviour. If you go too small you end up with basically gibberish even on modern models like Gemini 2.5.
Mercury has a 32k context window according to the paper, which could be why it does that.
I've run into this even with the modern million context length that 2.5 Pro offers, it kept trying one of a handful of failed approaches, realizing its failure, and looping without ending its train of thought until I yanked the tokens out of its mouth.
Even though it has gotten drastically better and rarer, I think this is going to be one of the failure modes that's just fundamental to the technology.
I think that's a prime example showing that token prediction simply isn't good enough for correctness. It never will be. LLMs are not designed to reason about code.
I had this happen to me on Claude Sonnet once. It started spitting out huge blocks of source code completely unrelated to my prompt, seemingly from its training data, and switching codebases once in a while... like, a few thousand lines of some C program, then switching to another JavaScript one, etc. it was insane!
That new Rhombus language that was featured here recently has an interesting feature where you can use `_` in a function call to act as a "placeholder" for an argument. Essentially it's an easy way to partially apply a function. This works very well with piping because it allows you to pipe into any argument of a function (including optional arguments iirc) rather than just the first like many pipe implementations have. It seems really cool!
ublock Origin already has a feature called "strict blocking" which does the same thing. In fact, the placeholder page that this extension takes you to looks almost exactly the same as the one that ublock origin uses.
Does that feature really send each URL you attempt to browse to a bunch of third-party services to be verified before it lets you browse them?
Edit: Made some not-very-thorough research and it seems like "strict blocking" in uBlock Origin does not do the same thing. It does local lookups against regularly updated filter lists. Like all of uBlock Origin's blocking, I guess.
Osprey is entirely asynchronous. It doesn't hold pages at all. If you visit an unsafe website, you might see it for 50-250ms before the connection is stopped.
A project's creator stepping down but having a successor is a strong good sign for the longevity of an open-source project. Whenever I see that transition happen, I think better about the project's long-term future.
the website is just a blank black page for me no matter how long I wait. clearly that's not what it's supposed to be going by the other comments, so that's a bit disappointing.
It takes a lot of humility to admit that the language just isn't as popular as it once was anymore, so kudos for that. The turn towards making the language more approachable to beginners is an interesting one for Scala, and I think it could have a positive impact on the language.
On the few sites I've seen using it so far, it's been a more pleasant (and cuter) experience for me than the captchas I'd probably get otherwise. good work!
>Even the dynamic scripting languages like Python that you'd think it would be easy tended to need an annoying and often 100% boilerplate __init__ function to initialize them.
For this reason, I very much appreciate the dataclass decorator. I notice that I define classes more often since I started using it, so I'm sure that boilerplate is part of the issue.
I think this is called a negation type, and it acts like a logical NOT operator. I'd like it too, and I hear that it works well with union types (logical OR) and intersection types (logical AND) for specifying types precisely in a readable way.