@Jakman The language is 100% useless without the impure keyword, although if you wanted a CPU warming program, of course, Facilis is just for you! Even Haskell has some impurity.
Now seriously, there are other problems, the if statement is useless, as there is no way to use it without creating impure code, unless it's followed by an else, in which case it's better, but the only genuine use I could imagine would be an ifelse in which both statements return a value, besides that there's little to no use.
void only has use in impure code, a void function is automatically impure. There's plenty of other things I can't even begin to think of at the moment. We almost had mutable variables too!
@xxpertHacker I have created a paradigm that allows OOP and FP. When you call a method on an object it returns a new object with some modification. This technically follows Fp guidelines and allows you to still use OOP efficiently. for example Instead of
struct Car {tire_count:u32}
impl Car {
fn lose_tire(&mut self) {
self.tire_count -= 1;
}
You could have this
struct Car {tire_count:u32}
impl Car {
fn lose_tire(&self) -> Self {
return Car{tire_count:self.tire_count-1};
}
}
@Jakman That works nicely in theory, but it's absolutely terrible for low-level efficiency. Consider: every time you need to lose_tire, you're allocating a new Car object. And garbage-collecting becomes a must, since calling lose_tire multiple times quickly leaks memory. So, I'm not saying it's impossible or a bad idea — you could write an efficient compiler to overwrite the old car with the new car, but now you're basically just modifying the original car while wasting time overwriting the non-changed fields.
TL;DR: In theory, that works nicely. In practice, to make it efficient it becomes the same as just modifying the original object.
@CSharpIsGud True. But now what happens if other functions refer to the original object? You could end up with an impurity leak in pure functions. To do it correctly, you'd pretty much have to create a new object copy every time, but that leads to obvious problems.
So... extremely well-made garbage collector I guess?
@Jakman OOP isn't entirely independent of FP, they're not incompatible for any particular reason, it's just how OOP is normally used that affects it. Also, usually OOP is incredibly inefficient.
I was thinking about allowing 100% immutable structs to start with later, possibly developing into some twisted OOP, but who knows.
As of right now, I was preparing to focus on static arrays, destructuring, compile-time JavaScript-like syntax array spreading, and other array-related stuff, etc.
Facilis - A Low Level Functional Language
Facilis is a strongly typed functional language that aims to be low level. Facilis uses a hand-written recursive descent parser made with love.
Factorial Example
Demo: https://repl.it/@Facilislang/FacilisDemo#README.md
^ Has a user/password login program loaded by default. Read the README!
Source: https://repl.it/@Facilislang/Facilis
^ 2072 lines of C++!
@CSharpIsGud @Subarashi @xxpertHacker
If you want a truely functional language then every function should return a value. void should not exist
@Jakman Yeah, look closely and it has more than one problem preventing it from really being an actual FP language.
@xxpertHacker yep. That impure keyword
@Jakman The language is 100% useless without the
impurekeyword, although if you wanted a CPU warming program, of course, Facilis is just for you! Even Haskell has some impurity.Now seriously, there are other problems, the
ifstatement is useless, as there is no way to use it without creating impure code, unless it's followed by anelse, in which case it's better, but the only genuine use I could imagine would be anifelsein which both statements return a value, besides that there's little to no use.voidonly has use in impure code, avoidfunction is automatically impure. There's plenty of other things I can't even begin to think of at the moment. We almost had mutable variables too!@xxpertHacker I have created a paradigm that allows OOP and FP. When you call a method on an object it returns a new object with some modification. This technically follows Fp guidelines and allows you to still use OOP efficiently. for example Instead of
You could have this
@Jakman well, the language was never intended to be a pure functional lang.
@Jakman That works nicely in theory, but it's absolutely terrible for low-level efficiency. Consider: every time you need to
lose_tire, you're allocating a new Car object. And garbage-collecting becomes a must, since callinglose_tiremultiple times quickly leaks memory.So, I'm not saying it's impossible or a bad idea — you could write an efficient compiler to overwrite the old car with the new car, but now you're basically just modifying the original car while wasting time overwriting the non-changed fields.
TL;DR: In theory, that works nicely. In practice, to make it efficient it becomes the same as just modifying the original object.
@fuzzyastrocat Later we could probably secretly modify the original object behind the scenes.
@CSharpIsGud True. But now what happens if other functions refer to the original object? You could end up with an impurity leak in pure functions. To do it correctly, you'd pretty much have to create a new object copy every time, but that leads to obvious problems.
So... extremely well-made garbage collector I guess?
@Jakman OOP isn't entirely independent of FP, they're not incompatible for any particular reason, it's just how OOP is normally used that affects it. Also, usually OOP is incredibly inefficient.
I was thinking about allowing 100% immutable structs to start with later, possibly developing into some twisted OOP, but who knows.
As of right now, I was preparing to focus on static arrays, destructuring, compile-time JavaScript-like syntax array spreading, and other array-related stuff, etc.
@Jakman
What has society come to in order for you to say that?
@DynamicSquid Because it's not :D
@DynamicSquid Some tours through Vietnam
@Jakman that's just fp lmao
haskell internally does that iirc
@Jakman That's not a new paradigm, those are called lenses! :)
@Camto thanks