codebje

Plumbing is fractionally less regulated where I am and I am allowed to change my own taps washers, but a whole tap assembly falls under similar issues as a power switch.

(I wound up building a gaming PC, much more capable but much more than the cost of streaming over an equivalent lifetime - IF streaming services don't enshittify to cost more and deliver less over time, which we all know they will.)

There's a vast number of operators who won't even look at their site when its performance craters due to a scrum of crypto miners all competing for resources. Why waste time on sophisticated attacks trying to fly under the radar of competent admins who will detect you by your egress traffic anyway?

But parser combinators build your final parser out of little bits, and sometimes those little bits might be something potentially ambiguous, like "any number of leading zeros followed by a number" which needs to parse "0" as no leading zeros and the number 0, but "00" as one leading zero and the number 0.

Non-deterministic parsers can easily blow out with backtracking much like careless recursive descent parsers, though.

The question is capabilities. Either gives you an error result that might be useful. List gives you backtracking and, depending on your grammar, multiple parses. Maybe is like a weaker Either. Other monads might do other interesting things, but from the perspective of accepting strings satisfying a grammar, List is the choice that supports non-determinism.

(Laziness strongly recommended.)

The poem is not mine, I believe it is Conor McBride’s.

    A parser for a thing
    Is a function from a string
    To a list of pairs
    Of strings and things.

(Successfully running Windows games is its own issue: I think "Steam Deck" compatibility badging is a pretty reliable tell for Linux gaming, but on a Mac, having the game be playable is a gamble on install and again with every patch.)

    Date,Amount,Account Number,,Transaction Type,Transaction Details,Balance,Category,Merchant Name,Processed On

We know how to apply LLms to problems, which is a subtly different thing to understanding how they do what they do. It's similar to fire: I can cook using fire, but I don't really understand how fire _works_. Heat+oxygen+fuel, sure, but what goes on chemically? I dunno. Doesn't stop me using it. (Pretty sure _humanity_ knows how fire works, though).

As an example, register allocation is graph colouring, and thus NP complete; a model for producing an allocation plan is learning heuristics that might look at more features in combination than the ones hand-crafted into the compiler. An LLM for the job might do better than a more focused model like a GNN, due to sheer size, the effectiveness of transformers, or magic. But it probably won't do an overall better job than the handcrafted heuristics, because those handcrafted heuristics also tend to compile very, very fast with a small memory footprint, and can be debugged (more) easily when they go wrong.

1. It's not a ban on using social media, it's a requirement for age verification to create an account. This only limits usage on the few platforms that force an account to do anything.

2. The technical controls platforms implement are, unsurprisingly, generally quite weak. Kids are crafty enough to circumvent them, and share how freely.

3. Wannabe-influencer parents just create accounts for their kids, making the circumvention trivial.

4. There are no consequences for using a social media account while under 16.

I think the final point is the main one, though. By design there's no mechanism in place for the government to take any action if a kid gets onto social media, only if a platform fails to implement age checks that satisfy the legislation's criteria. So platforms all implemented tokenistic age checks. Platforms don't care, or need to care, if they get bypassed. The government doesn't care.

If I were a more suspicious man I'd say that either the point was never to reduce the use of social media by kids in the first place, or it was well intentioned but railroaded into toothlessness by lobbyists.

If phone support issued an encrypted decrypt code that could only be used with your challenge code to decrypt the decrypt code, replay wouldn't be as trivial.

Every CD is identical, so no matter how iD went about this there's only ever one decryption key (per title, I assume) and those keys must either have been encoded in iD support's response, or already stored on the CD. TestDrive sold iD on the notion that the process was too hard for hacker groups to reverse engineer, and it wasn't.

If Quintauris successfully makes a RISC-V range for automotive use, there'd probably be margin to clone those and sell at a profit, but skirting automotive certification regulations is a high-risk game that (hopefully!) doesn't have many buyers.

If they make an IoT line, again, there might be margin in it, but you'd be trying to fit in between buyers willing and able to engage with Chinese sellers but for some reason unwilling or unable to engage with existing Chinese sellers of existing IoT RISC-V parts. Quintauris is a very, very long way away from being a "household name" along the lines of STM32 or FTDI.

But your more typical use case was to play a single tone for some significant fraction of a second.

I do not believe that emoji like crosses and ticks are particularly common at all, for any language, but LLMs seem to have picked up heavy use of them from somewhere and inserted them into code (and everything else) they generate.

LLM training sets will very likely include the massive corpos of non-English open source code from sites like Gitee, but would be unlikely to generate responses heavily influenced by them unless you've done specific things to make that happen - prompt in Chinese, try to make use of a library only available with Chinese source and/or documentation, perhaps. I've not seen it happen, but I am a light user of LLMs.

Equivalence of terms is an efficient tool for verification; I suspect that isn't really in the set of goals for Fuse, though.

Much as I loved DR-DOS, it did have occasional compatibility hiccups.

As I understand supercompilation, it's an extension of partial evaluation - optimisation is done on a graph of possible execution traces. The downsides should be obvious: execution traces rapidly grow massive, compilation resources grow superlinearly, and there are many cases in which the result is worse than the original.

What value would Fuse get from equivalence of terms, do you think?

It looks like a tidy little functional language - a small, easily grasped syntax surface and generally clear semantics. That you've got it to the point that it can compile and run proper programs is a great achievement for a solo dev project!

The string type in the standard library isn't Unicode-aware, might be worth just noting that. Unicode support can be a big undertaking, but considering whether you'll add it later or not might affect your library design now.

I don't really understand why you have an IO monad. The language isn't pure - `.exec()` means any function can perform IO actions no matter its type signature - so what's IO really for?

Do `impl` additions export? What happens when two libraries add the same function name with different signatures (or just bodies!) to a type's `impl` ?

Is currying automatic? It doesn't seem to be, but, eg, the `sum(x: i32, y: i32)` function theoretically could be called as `sum(5)` to create a closure, but this isn't a documented feature if so.

The website's font is using ligatures, not unicode operator symbols - I'd personally find it much clearer to use a non-ligature font to show what's really there, but that's immaterial to the language.

Perhaps that's the same thing as what you're saying, though: we don't specify these things in detail because it's expensive to spend that much time thinking through it all, when users are largely trained to just accept crashes, glitches, inconsistencies, and the occasional sprinkle of data loss.

Formal verification at the undergraduate level, if you even see it, would be about running software on a spherical cow, though.

The sort of environments in which this is a problem would be extremely uncommon. For a start, you need continuous contention. If you ever get a break in contention you no longer have starvation, and you 'reset' the ticket number monotonicity - to zero, if you actually take a maximum of entering thread ticket numbers instead of a cheap global counter.

If you do actually have an environment in which you expect to have continuous contention over a critical section, some quick napkin math can tell you if it's something to worry about based on the running time of your critical section. If it's over, say, 10ms, you've got a few years of runtime before it's a problem. If it's under 1ms, maybe you want to use 64-bit arithmetic for your ticket number so you can run your system until long after the human species is extinct.

You probably got a 'B' because you didn't give the professor the answer they expected, though, not because of any technical reasons.