ATS-Postiats
The-Spiral-Language
Our great sponsors
ATS-Postiats | The-Spiral-Language | |
---|---|---|
18 | 33 | |
349 | 903 | |
- | - | |
0.0 | 9.6 | |
about 1 year ago | 3 days ago | |
ATS | Python | |
GNU General Public License v3.0 or later | Mozilla Public License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
ATS-Postiats
- What is the most feature-rich programming language
- Evolutie limbaje in industrie
-
The Little Typer – The Beauty of Dependent Type Systems, One Step at a Time
This is one of my two favorite books in The Little ...er series. The other is The Rational Schemer. These are two of the most advanced books in the series.
The Little Typer provides an introduction to dependent types. These can by used to guarantee things like "applying 'concat' to a list of length X and list of length Y returns a list of X+Y". It is also possible, to some extent, to use dependent types to replace proof tools like Coq. Two interesting languages using dependent types are:
- Idris. This is basically "strict Haskell plus dependent types": https://www.idris-lang.org/)
- ATS. This is a complex systems-level language with dependent types: http://www.ats-lang.org/
The Rational Schemer shows how to build a Prolog-like logic language as a Scheme library. This is a very good introduction to logic programming and the implementation of backtracking and unification is fascinating.
This is an excellent series overall, but these two books are especially good for people who are interested in unusual programming language designs. I don't expect dependent types or logic programming to become widely-used in the next couple generations of mainstream languages, but they're still fascinating.
-
Does Rust have any design mistakes?
Not being ATS
-
The case against an alternative to C
> any safety checks put into the competing language will have a runtime cost, which often is unacceptable
This is completely wrong. The best counterexample is probably ATS http://www.ats-lang.org which is compatible with C, yet also features dependent types (allowing us to prove arbitrary statements about our programs, and check them at compile time) and linear type (allowing us to precisely track resource usage; similar to Rust)
A good example is http://ats-lang.sourceforge.net/DOCUMENT/ATS2CAIRO/HTML/c36.... which uses the Cairo graphics library, and ends with the following:
> It may seem that using cairo functions in ATS is nearly identical to using them in C (modulo syntatical difference). However, what happens at the level of typechecking in ATS is far more sophisticated than in C. In particular, linear types are assigned to cairo objects (such as contexts, surfaces, patterns, font faces, etc.) in ATS to allow them to be tracked statically, that is, at compile-time, preventing potential mismanagement of such objects. For instance, if the following line:
val () = cairo_surface_destroy (sf) // a type error if omitted
-
Security advisory: malicious crate rustdecimal | Rust Blog
For a low level language in which you actually need to prove that your code doesn't cause UB, see http://www.ats-lang.org/
-
Why is ATS not considered in the design of modern system languages?
Here's the homepage fo the language: http://www.ats-lang.org/. The trick to finding results about with google is to search "ATS programming language".
-
ESPOL, NEWP, Mesa, Cedar, Modula-2, Modula-2+, Modula-3, Oberon, Oberon-2, Component Pascal, Active Oberon, D, C#, F#, VB, Ada, Go, Swift, just a few examples.
In SPARK's case, you have to state your invariants in even greater precision than in Rust, and naturally it has worse inference. That's okay, the same happens in a certain language with Atrocious Type Syntax.
-
What are all the situations you can't do compile time type-checking when building a programming language?
Yes, things like mentioned in the post can be expressed and checked statically, as demonstrated by languages like Idris and ATS. ATS might be even more relevant as it's an imperative language too, it can get rather low-level (like talking about properties of C runtime functions) while proving required properties statically, and it includes a solver for certain amount of arithmetics so that you don't need to prove obvious mathematical identities to the compiler. http://www.ats-lang.org/
- Is it possible to make a functional programming language that is equivalent of Rust in terms of performance and resource efficiency?
The-Spiral-Language
-
Does This Language Exist?
Try Spiral for a functional response to the system level programming demands. It has an F#, C, and a Python backend.
-
How do I get around the lack of MailboxProcessor in Fable?
I did the language server for Spiral using Hopac. It involved turning the entirety of what would have been the sequential compilation pipeline into a promise stream.
-
Are there any good resources on reflection in Fable?
Sigh, despite using F# for so long, I've always avoided tackling .NET reflection, but I know from experience (of programming in Spiral) that this is a perfect place to introduce these techniques. Type systems like F#'s really hit their limits when it comes to serializing data across platform and language boundaries, so this is The place to demonstrate the use such methods.
-
why isn't functional more popular?
But a language that support programming in a staged functional programming style, like my own Spiral would actually be very suitable for gamedev, I think more than C# itself. It has compiler guarantees for a lot of things that F# doesn't, and what in other languages would require metaprogramming is just regular programming in it.
-
Ask HN: How do I get the most benefit out of my programming language?
I originally started work on [Spiral](https://github.com/mrakgr/The-Spiral-Language) back in late 2016 because I wanted a functional language in which I could program novel AI hardware that hadn't existed at the time, and still doesn't, but it won't be long before it arrives. It took 3 years of full time work to get it to its current standard of quality, and I'd really feel comfortable programming new hardware devices in my favored functional style. I've designed Spiral so it is both extremely powerful, easy to use while being efficient enough to program devices like GPUs that can't even use heap allocation for their objects.
I am not really concerned about what I'll do when I get access to Tenstorrent chips in six months; my personal needs for the language are met. But I would like it if I could spread the language more broadly, make it useful for people other than myself and get people to sponsor my work on it.
Here is the value proposition of Spiral.
It is a high-level functional PL that has some features that other languages don't, but that isn't really the point. On mainstream devices like the x86 ones there are a lot of programming languages that are good, and it would be tedious to use Spiral to compile to such platforms compared to using such languages directly. It is a bit how ReasonML compiles to JS. Back when I tried it I found using Typescript easier to deal with. So that is not where I'd like to go into, though using Spiral would have benefits in certain areas.
Rather, while reading the [CNX blog](https://www.cnx-software.com/) I realized that while consumer facing AI chips are not here yet, there is a lot of hardware development in the embedded space. They are heterogenous architecture. They have GPU and TPUs in addition to CPUs. And these cross platform interactions within the same system is something that existing languages are really poor at tackling.
If you look at Python or C#, for example, you can't really program the GPU on them directly. They are CPU focused, and don't have the right semantics and would be too inefficient to program devices like GPUs directly. The way I've designed Spiral is that you can program the CPU and the GPU and whatever else from within the same language.
It is not suitable for just GPUs, check this [demo out](https://github.com/mrakgr/PIM-Programming-In-Spiral-UPMEM-Demo). I recently did a backend for UPMEM devices, which are the first commercialized Process-In-Memory chips. I've posted the link to this on HN yesterday and on the Reddit embedded sub, but I got zero interest. And this is really a pity because that map kernel I've demoed is actually a big deal. Back when I first started working on Spiral, it took me 1.5 years of full time work to get to the point where I could write a program like that in the language. And without backend nesting of the kind that Spiral offers, it is impossible to write those kinds of programs no matter how skilled one is as a programmer.
The kind of backend nesting I've demonstrated is not something you can do in F#, Python or any of the languages that I know of. I could easily create such backends for many kinds of hardware. And people would benefit from that because unlike the mainstream computing devices, the hardware coming down the pipeline will have poor language support, nothing on the level of what Spiral offers. For the kinds of heterogeneous architectures I am envisioning, the language designs that are good in the CPU-dominant era, will simply not be suited in the heterogeneous era.
I need chances to demonstrate how good Spiral is, but I am not sure how to get them. If I do not get them, the future of computing will be a lot worse off. I wasn't there when Cuda was incumbent so I missed the boat on that, but I'd like it if Spiral became dominant on future computing devices. Not because I was the one who made the language, but simply because no other design is as suited for them.
-
PIM (Processing-In-Memory) Course
I am not shameless enough to plug Spiral in the main post, but if you are a PIM company or an user of them and want better PL support and tooling, get in touch with me. I'd love to get a chance to play with them.
-
September 2022 monthly "What are you working on?" thread
Two months ago I did a ref counted C backend for Spiral so I might as well plug it now. Since then I've gotten tired of 3d art, and decided to just start writing Heaven's Key.
-
Callbacks without closures?
I just happened to notice that Spiral has a C code generator now. Maybe you can just use that since it's designed with staging in mind and avoiding heap allocation.
-
Multistage Programming / First Class runtime compiler support
Spiral
-
Are there examples of programming language compilers that evaluate the side-effect free parts of the program at compile-time?
Another term to search for is partial evaluation. An interesting language that by default evaluates everything at compile time is Spiral, developed by someone frequenting this subreddit.
What are some alternatives?
lean4 - Lean 4 programming language and theorem prover
lust - A fast, auto-optimizing image server designed for high throughput and caching; Now that is hot.
chapel - a Productive Parallel Programming Language
kuroko - Dialect of Python with explicit variable declaration and block scoping, with a lightweight and easy-to-embed bytecode compiler and interpreter.
cicada - An old-school bash-like Unix shell written in Rust
gaiman - Gaiman: Text based game engine and programming language
c3c - Compiler for the C3 language
exp-flow - experimental rule-based programming formalism under construction [Moved to: https://github.com/contrast-zone/canon]
virgil - A fast and lightweight native programming language
cish - Go + Generics + Sum Types
HVM - A massively parallel, optimal functional runtime in Rust
Vale - Compiler for the Vale programming language - http://vale.dev/