81–90 of 98 posts
Hey, author here. I definitely didn't expect to see Tao on Hacker News. As is probably obvious, the language is extremely early in its life, and it's not practical to write anything but trivial examples in it yet. Please don't judge!
One question: does numerical destructing require that one of the terms be a constant? What happens if I write y ~ a + b ?
Also:
> In Tao, arg:f is shorthand for f(arg)
Did you mean arg -> f ?
The promises are great, but will it deliver? It’s seems the language has a really huge scope with lots of hard problems to solve. The thing I loved about golang was that it’s just “good enough” in lots of areas instead of being the best or perfect. That allowed more time ti works on other parts of an ecosystem. But since Tao is an hobby project, i just hope the author goes nuts and enjoy working on all those things.…
I am indeed "going nuts"! As mentioned in the README, I don't see Tao as a production-quality language (at least, for the foreseeable future). I'll leave that to the experts. Instead, I'm more interested in exploring the limits of new language design ideas (effect systems in particular). There are already a few interesting things Tao does that I've not seen elsewhere.
> Totality Best of luck. Dhall is a current language with totality, but it runs into impossibly high memory requirements as a result. We had CI workers with 16 GB RAM run into out-of-memory issues because of the sheer size of the totally expanded type space (sum types of types which are themselves sum types of types which are themselves sum types etc... Exponential growth is easy). I appreciate that this is scoped as…
I'm not sure what you mean with totally expanded type space. But it sounds like Dhall has an issue with unfolding/normalisation. Totality shouldn't have any special impact on memory usage as far as I know. It just restricts the kind of recursive functions and data types you can write.
Earlier quoted context omitted.
Tao looks super cool, and similar to the kind of language I'd personally make if I decided to create one. Kudos for actually implementing yours! Some specific questions about the language design: - Does your flavor of algebraic effects allow distinct effects of the same type (e.g. two separate int-valued `State`s)? I haven't seen anyone talk about this, but it seems like a potential problem with effects. - Do you hav…
> Does your flavor of algebraic effects allow distinct effects of the same type Could you give an example of what you mean by this? Multiple effects can be combined together (although I'm still working on handlers for multiple effects), for example: effect console = input + print fn greet_user : console ~ () = { print("Please enter your name:")!; let name = input!; print("Hello, " ++ name)!; } > Do you have plans for…
I mean a type like `yield Nat + yield Nat ~ ()`. Here's how this would occur naturally: Define
effect yield A is A => ()
fn yield_each A, B, e : (A -> e ~ B) -> [A] -> e + yield B ~ () is
| _, [] => ()
\ f, [a .. as] => a->f!->yield!; as->yield_each(f)
fn print_each A, B, e: (A -> e ~ B) -> e + print ~ () is
f, l => l->yield_each(f)
handle yield B with x => print(x->show)!
fn foo : print ~ [Nat] is
[1, 2, 3]->my_map(n => yield(n)!; n+1)
handle yield Nat with n => print("Processing " ++ n->show)!
Earlier quoted context omitted.
> Does your flavor of algebraic effects allow distinct effects of the same type Could you give an example of what you mean by this? Multiple effects can be combined together (although I'm still working on handlers for multiple effects), for example: effect console = input + print fn greet_user : console ~ () = { print("Please enter your name:")!; let name = input!; print("Hello, " ++ name)!; } > Do you have plans for…
> Could you give an example of what you mean by this? I mean a type like `yield Nat + yield Nat ~ ()`. Here's how this would occur naturally: Define effect yield A is A => () fn yield_each A, B, e : (A -> e ~ B) -> [A] -> e + yield B ~ () is | _, [] => () \ f, [a .. as] => a->f!->yield!; as->yield_each(f) fn print_each A, B, e: (A -> e ~ B) -> e + print ~ () is f, l => l->yield_each(f) handle yield B with x => print(…
Hey, author here. I definitely didn't expect to see Tao on Hacker News. As is probably obvious, the language is extremely early in its life, and it's not practical to write anything but trivial examples in it yet. Please don't judge!
Actually looks pretty interesting and impressive to me. One question: does numerical destructing require that one of the terms be a constant? What happens if I write y ~ a + b ? Also: > In Tao, arg:f is shorthand for f(arg) Did you mean arg -> f ?
Yes, the general pattern is `n + K`. I'm looking to expanding this to other operations in the future too.
> Did you mean arg -> f ?
Yes. I changed the syntax recently, but forgot to change the README. Thanks for pointing this out!
Earlier quoted context omitted.
I am indeed "going nuts"! As mentioned in the README, I don't see Tao as a production-quality language (at least, for the foreseeable future). I'll leave that to the experts. Instead, I'm more interested in exploring the limits of new language design ideas (effect systems in particular). There are already a few interesting things Tao does that I've not seen elsewhere.
I just want to say that you’re awesome, and I love your attitude hehe.
A couple of months agow I had never tried functional programming languages. Having learned Rust in the past year (and loving it ) made me want to try out Haskell since I always wondered about functional languages and I likes Rust's strong type system. I go a bit dissappointed with Haskell, but right now I'm reading Tao's README and this looks like everything I've ever wanted ! I'm gonna try it out right now.
Can you expand on what disappointed you about Haskell. I’m not looking to convert you or anything, just curious.
Earlier quoted context omitted.
Can you expand on what disappointed you about Haskell. I’m not looking to convert you or anything, just curious.
Hi, do you have a link to your language? You teased it quite a bit and I'm very curious to learn much more.
Earlier quoted context omitted.
Actually looks pretty interesting and impressive to me. One question: does numerical destructing require that one of the terms be a constant? What happens if I write y ~ a + b ? Also: > In Tao, arg:f is shorthand for f(arg) Did you mean arg -> f ?
> does numerical destructing require that one of the terms be a constant? Yes, the general pattern is `n + K`. I'm looking to expanding this to other operations in the future too. > Did you mean arg -> f ? Yes. I changed the syntax recently, but forgot to change the README. Thanks for pointing this out!
OK, so what is the intended benefit of y ~ x + 1 over x = y - 1 ?
I can see an obvious benefit if I can write y ~ x + z where neither x nor z is a constant and the resulting semantics invoke some kind of mathematical constraint management system or backtracking search a la Prolog, but if I'm constrained to write things that can be trivially transformed into a binding I don't see the point.