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

A few good ideas in programming languages

prydt.xyz

Post reply on HN
Print view View original

41–50 of 64 posts

Re: A few good ideas in programming languages

#41

Post by buybackoff »

prydt wrote: post #26
buybackoff wrote: post #13

A genuine question: is the first point (flow typing / type narrowing) a subset of or intersection with or just an alias to SSA (static single assignment)? I'm playing with a small interpreted language implementation that is based on Lua, and have reached a point where I want to implement a single-pass SSA (there is a nice short CS paper on this), but cannot get my head around all the concepts, even if I need proper S…

What's the nice short paper? (I'd be interested in reading it!)

Brandis, Marc M., and Hanspeter Mössenböck. "Single-pass generation of static single-assignment form for structured languages." (https://bernsteinbear.com/assets/img/brandis-single-pass.pdf).

Re: A few good ideas in programming languages

#43

Post by mrkeen »

buybackoff wrote: post #38
mrkeen wrote: post #29

Earlier quoted context omitted.

No. Type systems are unrelated to abstract machines which are unrelated to usability. Type inference/checking happens early in the pipeline. SSA is a way of laying out assembly instructions for an abstract machine. I say abstract because real machines re-assign values to the same addresses over time (which is precisely what 'single' static assignment prescribes against). Once you know which registers your real machin…

My idea was that with single pass, I can build SSA form during AST construction, and use phi-nodes to update type flow info. Then I could use SSA form to prove that I can use certain optimized bytecode instructions when a variable/register is known to be of certain type (I have virtual registers and fat instructions, eg ADD takes 2 sources and destination). Maybe I'm mixing control flow, type flow and SSA. I do not u…

Yep, this sounds like conflating two different ideas about SSA.

You could parse a source language with shadowed variables into an AST, and then one of your earliest AST transforms could be a 'de-shadowing' pass. The resulting AST would only see variables assigned only once.

Then a type-inference pass, where your AST expressions would gain type info.

(Then a bunch more passes, e.g. closure conversion if you have them)

Then towards the end you could lower your typed AST into a typed instruction list (having the SSA property - but nothing to do with allowing variables and their types to shadow earlier in the pipeline)

Re: A few good ideas in programming languages

#44

Post by Garlef »

leoc wrote: post #40

If you're serious about doing OO with static typing as well as (of course) mutability, you basically have to have something like flow typing to keep away the circle/ellipse nonsense. (In so far as flow typing is really static typing at all!)

Yes... But I think this only tells half of the story.

What if you pass a reference and mutate the object inside the function?

Re: A few good ideas in programming languages

#45

Post by tikhonj »

prydt wrote: post #34

I didn't expect this to get posted here. Long time lurker here. I'm really interested in programming language design and ergonomics. What niche PL features would you like to see have more adoption?

Row types are great. I'm doing a PureScript project right now and absolutely love having row polymorphism.

I'm also a fan of effect systems, although I haven't used them as much. Having an IO type in Haskell is great, but the ergonomics aren't (among other things, you get async-like function coloring). Effects seem like a much nicer, more composible way to get the same benefits.

Re: A few good ideas in programming languages

#46

Post by jkhdigital »

jauntywundrkind wrote: post #12

I feel like languages are playing around different paints if coat mostly, and not trying to build more meaningful programming experiences. I'd love to see a language whose pitch is that they have very next level stdlibs builtin. Effect for example is basically a mini stdlibs unto itself. It would be amazing to see such a principled deliberate craft applied to a language. Scope, layers etc etc etc etc: make visible, m…

Most of my research conversations with Claude nowadays are basically about this—what it would take to make every latent bit of program semantics visible and expressible in the language itself. As you put it, first-class everything.

At this point I think we have good solutions for expressing pretty much all the most common program semantics, but there’s no language that brings them all together under a unified syntax, tooling, etc.

Re: A few good ideas in programming languages

#47

Post by jkhdigital »

sick_of_slop wrote: post #20
joshmarinacci wrote: post #18

Earlier quoted context omitted.

Programming language innovation is measured in decades. I expect LLMs will make it easier to prototype new concepts, but adoption will still progress on a human timescale

The marketing pitch for these things was that they were supposed to induce "cambrian explosion of creations". That there was zero barrier to building anything anymore. This is surely true in programming languages especially, considering how fast LLMs took over software development? Surely this would mean we would get new ideas faster if that was the case? There is literally nothing stopping language designers from ge…

We don’t need new ideas, we need languages that take the best ideas developed over the past decade of PL research and operationalize them in a language with modern tooling and build support.

Re: A few good ideas in programming languages

#48

Post by spankalee »

Nice list. I have a new language I'm working on (called Zena: https://zena-lang.dev/) with all of these in some form:

If you have static types and unions, control-flow analysis and narrowing is critical for avoiding an excessive amount of casts - and if you also have pattern matching, you get very nice style where a type-check, state extraction, and branch are all one expression.

Borrow checking. Zena is a GC'ed language, but it runs in Wasm and lots of Wasm resources are external, so Zena has affine types and second-class values for managing resources and disposing of them when no longer used. GC + borrowing is a great combo because you don't need borrowing for everything and lexical lifetimes with a few escape hatches cover most things. The ownership system is also great for modeling structured concurrency.

I'm working on contracts after borrow checking is complete. My impetus there is AI-generated code. If humans still review at all, reviewing the contacts more than the implementations makes managing large amounts of changes easier.

I'd like to see a few more good ideas spread:

Formal verification. Contracts should be a good stepping stone into a spec language, from there a proof language and checker. This should also be good for AI-generated code.

Numeric unit types / units of measure with dimensional analysis. We should be able to say that a variable isn't just a f64, but a f64 of meters, and when divided by seconds, give a velocity. I don't know why this hasn't made it into more mainstream languages, but it seems like it makes programs more clear, not just statically safer. For synax, my plan is to parameterize scalars by units, like f64 vs f64 and have units like `m` and `s` be associated with dimensions like `length` and `duration`.

Async cancellation. I added cancellation as a first-class language concept in Zena so that it can be handled like exceptions, but aren't exceptions. It extends try/catch to try/catch/cancel/finally. When a task is canceled, a cancellation unwinds the stack starting from the next suspension point (await). The benefit here is that you don't have to remember to check for cancellation in async functions - they're all cancellable.

Re: A few good ideas in programming languages

#49

Post by layer8 »

prydt wrote: post #34

I didn't expect this to get posted here. Long time lurker here. I'm really interested in programming language design and ergonomics. What niche PL features would you like to see have more adoption?

I’m a big fan of checked exceptions, which are niche in the sense that only Java has them (at least among popular programming languages). However, Java lacks the ability to parameterize code over sets of exception types, which places limitations on how checked exceptions can be used with type-generic code. That’s something that can be improved.

Exceptions allow more flexibility in separating the success-case program flow from the error-case program flow, compared to return codes or union return types. Unchecked exceptions, however, have the same drawbacks as dynamic typing does. Checked exceptions are the static-typing equivalent.

Re: A few good ideas in programming languages

#50

Post by ModernMech »

sick_of_slop wrote: post #20
joshmarinacci wrote: post #18

Earlier quoted context omitted.

Programming language innovation is measured in decades. I expect LLMs will make it easier to prototype new concepts, but adoption will still progress on a human timescale

The marketing pitch for these things was that they were supposed to induce "cambrian explosion of creations". That there was zero barrier to building anything anymore. This is surely true in programming languages especially, considering how fast LLMs took over software development? Surely this would mean we would get new ideas faster if that was the case? There is literally nothing stopping language designers from ge…

https://www.reddit.com/r/AIprogrammingLanguage/
Post reply on HN