I'm not sure where that number comes from but I don't think it's right, and I don't think that's how La Liga is structured anyway. It's governed by an association of all of the teams in the top two flights of spanish football.
Right. The number is the result of Claude adding up the public information about the aggregate value of all those clubs plus the association. So it would mean buying all the clubs; or at least enough to have a controlling interest in the association. Clearly there are big challenges to that (e.g. clubs not being for sale for one). But I thought it was an interesting thought experiment. Of course if you're just trying to play the money = power card then it'd probably be cheaper to purchase the influence of some government officials.
Did Claude point out that under this proposal the Spanish clubs would be bared from entering European competitions? Since the clubs under the same ownership (more than 30%) can't enter the same UEFA club competitions.
I took a look at the test bench, and the Unlambda interpreter used supports like a third of unlambda, not including input. Since 79/80 of the tests require input, it isn't really possible to solve them. The best anything did on them was 1.2%, which is 1 test.
Doing something like that is basically the only way to write unlambda: you start with a lambda calculus (or scheme or whatever) and reduce the lambdas away mechanically. (This is in the unlambda docs!)
Because it can still race with C code using the standard library. getenv calls are common in C libraries; the call to getenv in this post was inside of strerror.
The problem is that applications sometimes need to set environment variables which will be read by libraries in the same process. This is safe to do during startup, but at no later times.
Ideally all libraries which use environment variables should have APIs allowing you to override the env variables without calling setenv(), but that isn't always the case.
> The problem is that applications sometimes need to set environment variables which will be read by libraries in the same process. This is safe to do during startup, but at no later times.
No, the problem is that libraries try to do this at all. Libraries should just have those APIs you mention, and not touch env vars, period. If you, the library user, really want to use env vars for those settings, you can getenv() them yourself and pass them to the library's APIs.
Obviously we can't change history; there are libraries that do this anyway. But we should encourage library authors to (in the future) pretend that env vars don't exist.
The place where it makes sense for a library to read environment variables is where the program is not written to use that specific library. For example, I can link a program whose author has never heard of TCMalloc against TCMalloc rather than the system malloc, and then configure TCMalloc via environment variables. This does not require modifying a single line of code, while manually forwarding configuration onto the allocator would. Another common example is configuring sanitizers. Not having to do anything other than pass another command-line switch to the compiler is one of the things that makes them really painless to use.
I do think you'd be hard-pressed to find a situation where a program calling setenv() to configure a library actually makes sense. It's a pretty strong sign that someone made a bad decision. People will, however, make mistakes in API design.
If env vars don't exist, that makes it much harder (and more likely impossible) for users to modify library/application behavior at run time.
I agree with you that it would be much better if, when libA needs to set behavio Foo in libB, it called libB:setBehavior (Foo) rather than setenv ("LibBehavior", "Foo")
But let's not throw the baby out with the bathwater.
I’d argue that libraries shouldn’t read environment variables at all. They’re passed on the initial program stack and look just like stack vars, so the issue here is essentially the same as taking the address of a stack variable and misusing it.
Just like a library wouldn’t try to use argv directly, it shouldn’t use envp either (even if done via getenv/setenv)
