@Jacob I've heard tinylisp is not too hard to learn, the core language is pretty small (it's a lisp). There aren't as many builtins as other languages, but that just makes it more fun. And not too many people use it (no offense DLosc)
I'm trying to contribute a minor PR to the Scala compiler and I can't even do that much because WSL crashes every few minutes and it takes so long to compile
How do people contribute to big open source projects?
Wow, I can't even start WSL now. This is just great
@mousetail lets say if the variable name is lowercase it is false, uppercase it is true, and if it is a vowel it is converted into an integer implicitly
@NumberBasher There are 1 char builtins for true and false already so there is really no use for anyone to use the variable access builtins for that purpose
@UnrelatedString It will also be the value of some other builtins, like the one that gets the "previous value" in interation if this is the first value
To summarise: it's being proposed that the default value of an empty variable be some constant literally named Undefined. This Undefined constant would also be the result of something like [][0]
@mousetail are you using raw generator objects provided by the language you're using or making some sort of wrapper class? (or something completely different?)
@lyxal I specifically want to make sure, if I need to convert to a array at any point (for example when reversing), it will apply to all copies so I don't need to do something very expensive multiple times
If I reverse a list, I don't want all copies reversed
I only want the list I want reversed to be reversed
And if you absolutely must allow the same LL reference to be in multiple places, then just update the internal generator and it'll automatically be in every reference
No you don't understand. Only that copy will be reversed. It's just all others would be converted to lists for efficiency prior the the reverse operation
If any of the others need their length checked later it would be more efficient
This is internal only, for the user of the langauge they wouldn't even notice the feature exists
though come to think of it... if you want to copy only when necessary, and/or apply it maximally, then every intermediate node, every tail of the list, would also have to track this
or i guess not so much force it as just forcibly evaluate all of it you'd probably not want to keep the previous elements if you know you won't use them
@mousetail The way we have it in vyxal, there's "known finite" and "known infinite". If you ask it to take the first five positive integers, it'll give [1, 2, 3, 4, 5] as a known finite list. If you ask it to take all positive integers less than 5 it'll give [1, 2, 3, 4... and because it's iterating over all items of an infinite list it'll continue computing terms even though it'll never find any.
It treats the latter case as infinite because, by any reasonable interpretation, it is.
In a certain chatroom, we like making acronym jokes about the build tool we use called sbt. While it usually stands for "Scala Build Tool", we aim to come up with all sorts of meanings, such as:
Stupid Brick Teeth
Sussy Baka Training
Shady Blue Tourists
Seriously Big Toes
Silly Bear Topics
Salac...
...also in trying to think of a solution, just want to make 100% sure that we can count on the wordlists being in the order of the acronym (and equivalently, the acronym can be taken as the order of the wordlists)
> For the acronym "sbt", you'll receive: the large text to change, the acronym, a list of words starting with "s", a list of words starting with "b" and a list of words starting with "t".
For anyone who follows this site, you may have noticed that Area 51 has been churning out progressively weaker site proposals and more anemic site launches, about a third of which fail in private beta.
There is nothing inherently wrong with most of these subjects; it's just that we've largely tap...
Because Err can be anything (usually something with the Error trait, thankfully), you have to do some pretty ugly stuff to get it to work with ?
Like -> Result<..., Box<dyn Error + Send + Sync>>
IMO there should just be a struct called, idk, Try<type> that can either be successful, or be any error type, and you declare error types as like, their own thing
So it'd basically just be a giant scoped global enum of error types, scoped in the sense that like, there'd be some organization
E.g., you could use some sort of keyword, let's say failtype, to add a custom error type. You could then access those in the same hierarchical way as structs and functions, like std::io::UnexpectedEof
So you would have the base Try::Sucess(type) case, and then ones like Try::std::io::UnexpectedEof. So you can pass a Try anywhere without needing to worry about what type of error it holds.
And when you used ? to pass on an error result, you could maybe specify some sort of wrapper around the actual error. For example, if the function calling you doesn't care whether it's a std::io::UnexpectedEof or a std::io::UnknownError, you could just wrap that in a mylibrary::foobar::UnexpectedInputError
The compiler would keep track of every possible error type a given Try could contain, so that wrapping would be useful (since if later on my function could also return a std::io::BrokenPipe, the function calling me would then have a missing match case if it tried to handle different error types)
Hasn't the inversion of the collatz rules to divergate to infinity?
Like:
Even: 2*n
Odd: (n-1)/3
The result has to be the identity if you put the inversion in the orginal ruleset.
And I think the inversion always divergate proovable to infinity.
But the wrapper still contains the error being wrapped, so when debugging, you can see all the details
Since currently, I feel like actually handling an Err in Rust can be really annoying since it tends to be a bit vague what the actual possible errors are once you get into Box<dyn Error> territory
I think you need to store the entire call stack when you perform an effect?
I assume closures really complicate this, because there's a language called Effekt researching algebraic effects and it doesn't have first class functions (it has these things it calls "blocks", but you can't pass them around)
Or maybe it's just representing the type of a function with effects that's complicated, since OCaml doesn't have that restriction
Hmm, OCaml claims its implementation of effects is "very efficient" (source)
Okay, apparently you don't need the entire call stack, just enough for all the stuff inside your handled part?
I wonder why OCaml doesn't bother having effects in its type system too
Oh I see, it seems this is more of a preview feature so they want to wait until it's stabilized to have syntax and typing for it
@RydwolfPrograms the equivalent in java is checked exceptions. they are hated bc of overuse and forcing you to rethrow as a runtime exception a lot of times
Hasn't the inversion of the collatz rules to divergate to infinity?
Like:
Even: 2*n
Odd: (n-1)/3
The result has to be the identity if you put the inversion in the orginal ruleset.
And I think the inversion always divergate proovable to infinity.
