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

111–120 of 124 posts

Re: The Austral Programming Language

#111

Post by lelanthran »

rprospero wrote: post #59
angiosperm wrote: post #50

I appreciated that it listed "no destructors" immediately after the top-line "no garbage collection", so I didn't need to read any further. What it means is it offers no ability to encapsulate resource management, so not useful for me. That doesn't mean it is not useful to others.

From my reading of it, it does have what you're looking for. Specifically, while there are "no destructors", you are required to call a function to consume the value. Failing to consume the value is a compile time error. You can roughly approximate thinking about this as having destructors, but you're required to explicitly call them and the compiler won't let you write code that doesn't call the destructor.

This is nice. It does seem mutually exclusive with any early return though, like exceptions.

On the phone now so I only read the page on linear types, but will look at this closer when back at my desk.

In my own language I am considering destructors purely so that early returns are viable. I'd like to see if there is any alternative to destructors that aren't 'defer' or similar.

Re: The Austral Programming Language

#112

Post by JonChesterfield »

lelanthran wrote: post #111
rprospero wrote: post #59

Earlier quoted context omitted.

From my reading of it, it does have what you're looking for. Specifically, while there are "no destructors", you are required to call a function to consume the value. Failing to consume the value is a compile time error. You can roughly approximate thinking about this as having destructors, but you're required to explicitly call them and the compiler won't let you write code that doesn't call the destructor.

This is nice. It does seem mutually exclusive with any early return though, like exceptions. On the phone now so I only read the page on linear types, but will look at this closer when back at my desk. In my own language I am considering destructors purely so that early returns are viable. I'd like to see if there is any alternative to destructors that aren't 'defer' or similar.

Exceptions and linear types are difficult to combine. Implicit destruction is fine though, provided destruction can't fail.

Re: The Austral Programming Language

#113

Post by JonChesterfield »

_0w8t wrote: post #110
ZoltanAK2 wrote: post #98

Earlier quoted context omitted.

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

To statically ensure a stack overflow does not happen requires that recursion is rejected by the type system. Austral does not do that so the stack overflow is a dynamic condition similar to memory allocation failures.

Maximum stack usage can be calculated in the presence of recursion. Tail calls can be handled as branches instead of nested call frames, but also non-tail calls are tolerable if you have (or can infer) some measure to determine maximum call stack depth.

It's a pain, and the type system rejecting any recursion is certainly simpler, but that's not a strict requirement.

Re: The Austral Programming Language

#114

Post by lelanthran »

cpeterso wrote: post #73
Yasuraka wrote: post #37

Earlier quoted context omitted.

>the microscopic savings in key presses are just really such a strange thing to even debate It's about readability

Studies of program verbosity have shown that long vs short names have little impact in other programmers' reading comprehension or code maintainability.

TIL.

Do you remember which languages they looked at?

Re: The Austral Programming Language

#115

Post by lelanthran »

hardwaregeek wrote: post #75
jimbob45 wrote: post #42

Earlier quoted context omitted.

Shame they never fixed this. Would have been nothing to add a fn keyword at the beginning of all function definitions and then use the MS EEE strategy to bring it into the standard. Of the many changes the committee could make with C, I have to believe a function keyword would be among the least contentious.

Probably couldn’t since people could have named functions “fn”. Although idk, one keyword breaking in 50 years is probably excusable

Well they didn't mind trampling all over symbols that start with 'str', which is bigger breakage in my opinion, so they could have added a function keyword.

Re: The Austral Programming Language

#116

Post by radioknight »

seagreen wrote: post #13

Did not expect docs to be this exciting... On July 3, 1940, as part of Operation Catapult, Royal Air Force pilots bombed the ships of the French Navy stationed off Mers-el-Kébir to prevent them falling into the hands of the Third Reich. This is Austral’s approach to error handling: scuttle the ship without delay.

The creator of Austral writes good fiction https://borretti.me/fiction/

Re: The Austral Programming Language

#117

Post by meindnoch »

creata wrote: post #93
meindnoch wrote: post #78

Earlier quoted context omitted.

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

If you think about what templates are, it's not hard to understand why they must go completely in the header files. It's literally a source code template. It's a set of instructions to generate code at compile time, depending on the template parameters, hence 100% of the source code must be available at the point of instantiation. Just the interface is not enough.

Re: The Austral Programming Language

#118

Post by solomatov »

olodus wrote: post #99
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.

Yep, I agree with you that it's better to be explicit than implicit here. Initialization/destruction order is often tricky, and source of obscure bugs.

Re: The Austral Programming Language

#119

Post by _0w8t »

JonChesterfield wrote: post #113
_0w8t wrote: post #110

Earlier quoted context omitted.

To statically ensure a stack overflow does not happen requires that recursion is rejected by the type system. Austral does not do that so the stack overflow is a dynamic condition similar to memory allocation failures.

Maximum stack usage can be calculated in the presence of recursion. Tail calls can be handled as branches instead of nested call frames, but also non-tail calls are tolerable if you have (or can infer) some measure to determine maximum call stack depth. It's a pain, and the type system rejecting any recursion is certainly simpler, but that's not a strict requirement.

Inferring the number of loop integrations or recursion levels is in practice impossible when the number depends on the user input.

For a system language I would like to see that when the compiler cannot infer the bound on the stack size or when that static bound exceeds some static limit, a function call is treated as fallible.

Re: The Austral Programming Language

#120

Post by adamrezich »

meindnoch wrote: post #79
adamrezich wrote: post #66

Earlier quoted context omitted.

what's encouraging you to conceive of the build system and the language as separate things? I never understood why most people making new languages seem to want to have each of these be distinct—why not just define the build using the same language?

For the same reason I want my TV and media player to be separate devices, instead of an all-in-one "smart" TV.

it's not that I don't understand the analogy part of your analogy... I just don't understand how these things are actually analogous in any way.
Post reply on HN