Sorry, what's that font in the github screenshots?
Iosevka Fixed Slab Semibold
Tao: A statically-typed functional language
21–30 of 98 posts
Re: Tao: A statically-typed functional language
#22Earlier quoted context omitted.
Pretty much! The language does support limited sugar for tuples without parentheses in some specific cases, such as `match` and `let`: let x, y = 5, 4 in ... match x, y in | 4, 7 => None \ _, y => Just y However, these cases only incidentally lower to tuple pattern matching, and deliberately hide the fact that tuples are used internally.
Are you planning on having something similar to computation expressions? Altough, I guess thats basically covered within the do notation. https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...
Yes! As you say, the do notation + monads covers this, but I'm planning to remove it in favour of a slightly more general 'effect basin' syntax that I'm currently working on (syntactically similar to Rust's async + await, but generalised to all effectful operations like mutation, IO, etc.). Example here: https://github.com/zesterer/tao/blob/master/examples/mutate....
Re: Tao: A statically-typed functional language
#23The 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.
Came across this post [0] by Graydon Hoare (original author of Rust and member of the Swift team) in an HN comment the other day. Lots of interesting discussion about future paths for language design work, including some discussion of Effects Systems.
Curious how Tao is pushing the limits on that front?
Re: Tao: A statically-typed functional language
#24Earlier quoted context omitted.
Tao isn't indentation-sensitive, so nested `match` expressions are ambiguous without the trailing \ branch. I don't know whether I'll keep this syntax though. I'm increasingly wondering whether it's better to just bite the bullet and go all in with indentation sensitivity. That said, the existing \ syntax can be quite nice to read: https://github.com/zesterer/tao/blob/master/lib/parse.tao#L5...
Why not just require parents for nested cases? IMO this is fairly unambiguous, even to people unfamiliar with a particular language.
In a previous revision of the language, I did! (https://github.com/zesterer/tao/tree/old). I decided against it because, in short, I find the trailing delimiters to be quite ugly.
Because this is purely a personal project, I'm thankfully not constrained by such mundane concerns as "ergonomics" (unless such concerns relate to me while I'm working with it). I think Pythonic syntax is probably the way to go long-term though...
Re: Tao: A statically-typed functional language
#25A few observations: Seems very ML/Haskell inspired. All tuples seem to require parenthesis. Definitely not ergonomic on a qwertz layout (Altough, what language is?) No current plans for an interactive/repl version it seems No dependant types either. Overall, pretty interesting. Definitely warrants a closer look.
> No dependant types either.
You're funny
Re: Tao: A statically-typed functional language
#26Hey, 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!
Designing a PL is a hard complicated process, very slim portion of professional programmers are able to deliver some novelty here. I think any judgement should be treated as merely a feedback on the usefulness of this language. The effort alone is exceptional accomplishment. Take care.
Re: Tao: A statically-typed functional language
#27Hey, 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!
Designing a PL is a hard complicated process, very slim portion of professional programmers are able to deliver some novelty here. I think any judgement should be treated as merely a feedback on the usefulness of this language. The effort alone is exceptional accomplishment. Take care.
Thanks for your kind words :)
Re: Tao: A statically-typed functional language
#28A few observations: Seems very ML/Haskell inspired. All tuples seem to require parenthesis. Definitely not ergonomic on a qwertz layout (Altough, what language is?) No current plans for an interactive/repl version it seems No dependant types either. Overall, pretty interesting. Definitely warrants a closer look.
> No dependant types either. You're funny
How so? I personally find dependant types to be very interesting, but I get that they are a PITA to implement. So, for me, it was simply an observation that there are currently no plans for dependant types. No value judgement intended.
Re: Tao: A statically-typed functional language
#29Earlier 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.
Came across this post [0] by Graydon Hoare (original author of Rust and member of the Swift team) in an HN comment the other day. Lots of interesting discussion about future paths for language design work, including some discussion of Effects Systems. Curious how Tao is pushing the limits on that front? [0] https://graydon2.dreamwidth.org/253769.html
> Curious how Tao is pushing the limits on that front?
I don't want to put emphasis on "pushing the limits" because I'm still very new to language design and mostly self-taught. There are bigger and better languages pushing the envelope further than Tao!
That said, I've been experimenting with:
- Expressing totality and type inhabitance in the type system
- Effect systems (including user-defined effects, effect handling, parametric effects, lowering to monadic IO, etc.)
- Typeclass inference via typeclass variables (Tao can handle several cases that are ambiguous even in Rust, such as the following: https://github.com/zesterer/tao/blob/master/examples/debug.t...)
Re: Tao: A statically-typed functional language
#30Earlier quoted context omitted.
REPLs are often difficult to reconcile with AoT compilation and static analysis, particularly in the context of things like type inference (at least, in a way that preserves semantics). It's on my mental todo list, but not a priority for me.
How fast is the compiler? In many cases a report can just be syntactic sugar for compiling and running an accumulating log of source code lines. It’s not really important how it works under the hood as long as it’s mostly transparent to the user. As a side effect, it might also be a good way to keep your compile times down.
Fast enough for this approach to work for small examples. For longer examples, I'm less confident: I've yet to implement a proper module system (other than a slightly more principled version of C's #include) so this currently means compiling the entire standard library on every REPL line. Thankfully, the compiler can still handle this within about 100 milliseconds on my machine. Perhaps when I have a more rugged module system I can look into this more, thanks for the suggestion!