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

The Austral Programming Language

austral-lang.org

Post reply on HN
Print view View original

91–100 of 124 posts

Re: The Austral Programming Language

#91

Post by fijiaarone »

ralfn wrote: post #72
iroddis wrote: post #5

This quite a shallow observation, but I really wish new languages would cut down on verbosity and boilerplate. Making people type out “function” instead of “fn”, “def”, or nothing at all feels like unneeded friction. I’m not looking for APL levels of terseness, but I also don’t want to have my code mistaken for an essay filled with what amounts to scaffolding.

Have you ever seen the d3 javascript visualisation examples? The author has a physics background, so the code ends up being very verbose with lots of comments about simple programming stuff, yet incredibly terse when it comes to heavy mathematics. I would have done the opposite. It made me realize that people naturally want to be more verbose when they are less comfortable with the concepts and less verbose when they…

Or it means they cut and pasted the algorithm and don’t understand it.

Re: The Austral Programming Language

#92

Post by ZoltanAK2 »

renox wrote: post #29

I still didn't see in the documentation what's supposed to happen in case of overflow..

In accordance with the 'scuttle the ship' philosophy, Austral programs abort immediately when trapping arithmetic overflows, with the message "Overflow in trappingOpname (TypeName)".

Re: The Austral Programming Language

#93

Post by creata »

meindnoch wrote: post #78
jll29 wrote: post #51

For me, this is of interest: Austral’s module system is inspired by those of Ada, Modula-2, and Standard ML, with the restriction that there are no generic modules (as in Ada or Modula-3) or functors (as in Standard ML or OCaml), that is: all modules are first-order. Modules are given explicit names and are not tied to any particular file system structure. Modules are split in two textual parts (effectively two files…

>It was a mistake how C++, Java and other languages forgot to split interface declaration from implementation definition Huh? C++ is split into header files (interface) and cpp files (implementation)...

But there's no .cpp file for many (most?) uses of templates.

Re: The Austral Programming Language

#94

Post by webkike »

zetalyrae wrote: post #67
imglorp wrote: post #49

Flashbacks to TA'ing freshman programming 101 in Pascal: every student got hung up on when to use a period or semicolon or end. And from Austral's fib example (snipped) module body Fib is function fib(n: Nat64): Nat64 is if n We here all understand BNF, Ada, Modula, etc and parsing but imagine explaining to the first day student: Why is there no "end function" like for the other contexts? When do I use a semicolon vs…

Declarations don't need `end function` because it's always clear what you're closing. Statements need an `end if`, `end for` etc. because it lets you find your way in nested code. The rationale for the syntax explains it a bit: https://austral-lang.org/spec/spec.html#rationale-syntax FWIW I will probably get rid of the `module is ... end module.` bit because it adds unnecessary nesting.

Why? No ability to nest functions? Why do you need a semicolon at the end of "end"?

Re: The Austral Programming Language

#95

Post by solomatov »

IshKebab wrote: post #38

> No arithmetic precedence. Interesting. I've wondered about this when making an expression parser. Obviously it makes parsing way easier and mistaken precedence is often a cause of bugs (especially in C where some of the operator precedence is plain wrong). But on the other hand that's got to be quite annoying surely?

Smalltalk has this "feature" and was doing fine. It was pretty popular at some point.

Re: The Austral Programming Language

#97

Post by _0w8t »

ZoltanAK2 wrote: post #92
renox wrote: post #29

I still didn't see in the documentation what's supposed to happen in case of overflow..

In accordance with the 'scuttle the ship' philosophy, Austral programs abort immediately when trapping arithmetic overflows, with the message "Overflow in trappingOpname (TypeName)".

Yet Austral returns optional types from any memory allocation function rather than calling abort.

And stack overflow is a memory allocation failure, so why is the discrepancy? I.e. for the language focusing on correctness this is an unfortunate omission.

On the other hand none of popular or semi-popular system languages allows to explicitly control stack consumption. Zig has some ideas, but I am not sure if those will be implemented.

Re: The Austral Programming Language

#98

Post by ZoltanAK2 »

_0w8t wrote: post #97
ZoltanAK2 wrote: post #92

Earlier quoted context omitted.

In accordance with the 'scuttle the ship' philosophy, Austral programs abort immediately when trapping arithmetic overflows, with the message "Overflow in trappingOpname (TypeName)".

Yet Austral returns optional types from any memory allocation function rather than calling abort. And stack overflow is a memory allocation failure, so why is the discrepancy? I.e. for the language focusing on correctness this is an unfortunate omission. On the other hand none of popular or semi-popular system languages allows to explicitly control stack consumption. Zig has some ideas, but I am not sure if those wil…

There is discrepancy because things the programmer can prevent are handled differently from things the programmer cannot prevent.

The programmer can always statically ensure that the program doesn't experience a trapped overflow, and that the stack size is not exceeded. All the information to do that is available when the programmer runs the compiler.

But there is no way to prevent a memory allocation failure when using `calloc`, since the information required to do that is not available when the programmer writes the code. In fact, when running on POSIX systems it's not even possible to check _in advance_ at runtime whether a memory allocation will succeed.

This is why Austral's allocateBuffer(count: Index): Address[T] returns an Address[T], which you have to explicitly null-check at run-time (and the type system ensures that you can't forget to do this).

Of course, on some non-POSIX systems such as seL4, the programmer can know at compile-time that memory allocations (untypedRetype) will not fail. When you use Austral on such systems, you don't have to use calloc/allocateBuffer at all.

Re: The Austral Programming Language

#99

Post by olodus »

solomatov wrote: post #96

> No destructors. What's the logic behind this? It's nice to have a way to pair resource usage with disposal. Or does the linear type system allows not to forget about the resources which have to be closed.

Yes, the compiler will remind you if you haven't cleaned up a value of linear type.

The 'no destructor' rule follows the 'no hidden flow' design, similar to Zig. Some doesn't like it, but personally I prefer it.

Re: The Austral Programming Language

#100

Post by ZoltanAK2 »

solomatov wrote: post #96

> No destructors. What's the logic behind this? It's nice to have a way to pair resource usage with disposal. Or does the linear type system allows not to forget about the resources which have to be closed.

Indeed, the linear type systems makes sure that you won't forget to dispose of resources.

Linear types enable manual memory management without memory leaks, use-after-free, double free errors, garbage collection, or any runtime overhead in either time or space other than having an allocator available. More generally, it enables us to manage any resource (file handles, socket handles, etc.) that has a lifecycle without letting us forget to dispose of the resource (e.g. leaving a file handle open), dispose of it twice, or use it after disposal (e.g. reading from a closed socket), all without runtime overhead.

The Austral tutorial's chapter on linear types (https://austral-lang.org/tutorial/linear-types) explains how this works in a fairly clear way.

Post reply on HN