Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tao: A statically-typed functional language

github.com

Post reply on HN
Print view View original

61–70 of 98 posts

Re: Tao: A statically-typed functional language

#61

Post by atennapel »

solatic wrote: post #59

> 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.

Re: Tao: A statically-typed functional language

#62

Post by shadowofneptune »

zesterer wrote: post #56
dataangel wrote: post #51

Earlier quoted context omitted.

> A rather dogged and obnoxious opinion of mine is that the 'optimisation ceiling' for statically-typed, total functional programming languages is significantly higher than traditional imperative languages with comparably weak type systems. Curious about plans for this. When Haskell use exploded I followed a lot of the blogs talking about it someday being faster than C because purity made compiler reasoning easier an…

So... I want to preface this by saying that I'm very, very far from being an expert on this topic. Although Tao's compiler has a MIR optimiser, it only covers the basics (inlining, constant folding + symbolic execution, etc.). I think one of the main reasons that Haskell failed to solve this is actually the same reason that many lower level languages failed: it places too many requirements on data representation. In…

> all functions are dynamically dispatched by default, with inlining being a speculative optimisation

Could you please point me to other approaches to inlining? I am also working on a personal language and it could be helpful.

Re: Tao: A statically-typed functional language

#63

Post by skavi »

zesterer wrote: post #29
landonxjames wrote: post #23

Earlier quoted context omitted.

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 handl…

would you mind explaining the linked code?

Re: Tao: A statically-typed functional language

#64

Post by zesterer »

shadowofneptune wrote: post #62
zesterer wrote: post #56

Earlier quoted context omitted.

So... I want to preface this by saying that I'm very, very far from being an expert on this topic. Although Tao's compiler has a MIR optimiser, it only covers the basics (inlining, constant folding + symbolic execution, etc.). I think one of the main reasons that Haskell failed to solve this is actually the same reason that many lower level languages failed: it places too many requirements on data representation. In…

> all functions are dynamically dispatched by default, with inlining being a speculative optimisation Could you please point me to other approaches to inlining? I am also working on a personal language and it could be helpful.

Rust gives each closure a unique type (see the `Fn` trait: https://doc.rust-lang.org/core/ops/trait.Fn.html), allowing the compiler to always statically dispatch to the exact function body at compile-time. That said, this is a rather more explicit approach that won't necessarily fit everything.

Re: Tao: A statically-typed functional language

#65

Post by jrumbut »

zesterer wrote: post #46
code_biologist wrote: post #45

Earlier quoted context omitted.

I remember a golden age of programming reddit and HN in the late 2000s that inspired me learn a bunch of new programming languages, Haskell the biggest influence among them. It seemed like people were always posting their own personal languages, lisps (I remember the hot takes on Arc lol), and such all the time. I have very fond memories of going through Jack Crenshaw's "Let's Build a Compiler" after seeing it posted…

Thanks!

I too remember that time and it left me terribly jaded about the utility of new languages.

This is the first I've seen in a while where I think the offering hits a spot on the tradeoff continuum that is distinctive and where I can picture many circumstances where I would want to use this language (the soundness aspect is a big part of that).

Re: Tao: A statically-typed functional language

#66

Post by zesterer »

macintux wrote: post #53
Akronymus wrote: post #52

Earlier quoted context omitted.

I did? I have now spent like 20 minutes trying to figure it out. But I still don't get it.

I'm guessing it has something to do with the keyword "either" and Haskell types, but I'm otherwise clueless. Every time I look at Haskell I run the other way.

I think it was "value judgement" (dependent types allow dispatching over a value in the type system)

Re: Tao: A statically-typed functional language

#67

Post by agumonkey »

zesterer wrote: post #10

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!

good luck

Re: Tao: A statically-typed functional language

#68

Post by zesterer »

iamwil wrote: post #55

What were the series of resources or readings that you did to help you create Tao?

There wasn't really any single resource I read. Frustratingly, I find it quite difficult to read research papers (I'm told it's a skill acquired with practice, but it's something I've never gotten into). Most of the implementation is the product of several rewrites and false-starts, along with the occasional hint I've read about here or there on the web.

Re: Tao: A statically-typed functional language

#69

Post by skavi »

pohl wrote: post #60
zesterer wrote: post #7

Earlier 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.

Do you suppose that might be an outmoded historical bias? I'm wondering if maybe the advancement of hardware has made it so that the costs of AOT compilation and a type system should no longer stand in the way of delivering a reasonable REPL experience. Swift's "playgrounds" seems to do alright — a real outlier in this regard.

Haskell has a REPL. No idea whether it’s considered good though.

Re: Tao: A statically-typed functional language

#70

Post by zesterer »

galaxyLogic wrote: post #54

What about OOP classes and inheritance? Data hiding? Modules?

Tao has typeclasses (like Haskell) that allow for compositional parameteric polymorphism. It also has data types (records, sum types, etc.) and functions, but deliberately does not bundle the two together.

There is no module system yet (only a temporary C-like #include system): that's on my list of things to work on!

Post reply on HN