@ericflo all of them.
I'm particularly interested if it can pick up "getting shit done" from a few examples and stop being an over-enthusiastic junior on Adderall.
@Flash They should be signing a free trade agreement... But they're penguins and can't sign treaties. Oh no.
@grumpy_website Learn more languages
That was Suno v3. Unfortunately v4 got better at musicifying prose, but arguably worse for working with verse. Also the sound got more bland, so v4 "remasters" are at best different arrangements.
I hope the upcoming models would pareto-improve and perhaps the 3rd album would be spectacular.
This is how you do 1 Apr pranks right: https://www.lesswrong.com/posts/YMo5PuXnZDwRjhHhE/lesswrong-s-first-album-i-have-been-a-good-bing
> Honestly, despite it starting out as an April fools joke, it's a really good album. We made probably 3,000-4,000 song generations to get the 15 we felt happy about, which I think works out to about 5-10 hours of work per song we used (including all the dead ends and things that never worked out)
@ericflo Can any frameworks pull tools from the state? If yes, the agent then can call a tool to search for an MCP, then "subscribe" to it. Looks pretty vibecodable.
@ericflo Just wait for the meta-MCP, a protocol to aggregate collections of tools
@rzeta0 Oops. I just spotted the missing "not"...
> It is "tail recursive", but now it "returns" immediately
Of course it is *not* tail recursive.
Technically (due to laziness of (:)) the call isn't even recursive by itself - it gives you a value right away. It just happens that you can pinch another value from the second argument of the cons. No recursion - no stack to blow - nothing to tail-optimize (=
@rzeta0 TLDR: It depends on the usage patterns.
If a consumer can work with a producer in lock-step, then the laziness allows to eliminate the intermediate list-building and operation on infinite streams.
Whenever you're working with Haskell lists (and other structures like it) you have to consider 3 situations: empty list [], finite list [1,2,3], and infinite list [1..].
The first two are quite simple. But the last one is the Haskell specialty which regularly breaks the typical advices given in other languages, even "functional".
Consider a case where the producer gives an infinite list (`nums = 36 : nums :: [Int]`).
You can't get a sum of it:
```
go !acc (current : rest) = go (acc + current) rest
go acc [] = acc
```
It is strict in accumulator and efficient, but never terminates on infinite input.
But you can get a stream of running sums:
```
go !acc (current : next) = acc : go (acc + current) next
go acc [] = [acc]
```
It is "tail recursive", but now it "returns" immediately and the caller can inspect its value.
The value happens to be the list constructor (:) and its two arguments. If you only need the current value (or a constant prefix), you don't have to calculate the rest at all. Doing nothing is even more efficient than tail recursion.
@vy @dabeaz @neutrinoceros At least the elevator cabin itself didn't crash from the top floor while the doors were open, cutting someone's stuff in progress.
(Gonna need some model checking to prevent that...)
@someodd can you use git url with a commit? This way you'd get the same clean package install without round-tripping through Hackage.
@someodd can you use git url with a commit?
@rzeta0 It's okay to skip the stack/cabal/etc if the code has no dependencies besides `base`.
Otherwise, switch to the project-based setup ASAP and save hours trying to figure out how to install stuff, where, and which versions.
Since the package they use for exercises has quite a few deps, you'd rather follow the suit and `ghcup install stack` or make yourself at least a minimal `cabal.project` (`packages: .`) and use `cabal ghci ...` instead.
Just don't try to `cabal install` - this way lies madness.
Apparently they use stack to install ghc too. That was superceded by ghcup.
@rzeta0 @jonocarroll I think this has roots in logic.
TLDR: There's a privileged element for "nothingness" and the rest are "something". So, for the types that map to some number it is natural to expect at least the 0th elements to align.
If you take numerical encoding of enums as an inductive type then there would be the "smallest" element - `Zero`, and the "next" element and you'd get the type `data N = Zero | Next N`. It can be used to encode all kinds of enums. But then, the same principle is used to encode e.g. lists: `data List a = Empty | Item a (List a)`.
So, why would the `False` go first then? Consider the function `len` that maps arbitrary lists to numbers: len Empty = Zero; len (Item next) = Next (len next).
The empty lists has no layers and so the number zero has no layers.
Recall my previous diatribe about multiple ways converging on the same outcome? Here we have another case of that. We can handwave the property being "has something". The lists have elements, the numbers have quantity, and the True is some bit being "on".
Exactly the same thing goes for the Maybe type, it's just more specific in what exactly it have got in there.
@jonocarroll @rzeta0 Collections are just example of doing things of least surprise. There is a web of concepts that are expected to behave similarly. If there are multiple ways to do the comparison, they ought to have same results since the underlying property is the same across all the implementations.
Toots as he pleases.