Mastodawn

I have thought about it and decided that all I should demand of the reference variables in hiha is that, at any given point, they match in name and to what they refer.

Thus all the stuff I said earlier about appending incremented numbers to variable names is probably now null and void...

#programming #programmingLanguages

sayzard 1d ago

Hardware Memory Models

이 글은 멀티프로세서 환경에서 하드웨어 메모리 모델의 중요성과 복잡성을 설명한다. 특히, 순차적 일관성(sequential consistency) 개념과 이를 보장하지 않는 현대 하드웨어(x86-TSO, ARM, POWER)의 메모리 모델 차이를 다룬다. 메모리 모델은 프로그래머, 컴파일러, 하드웨어 설계자가 프로그램 실행의 일관성과 최적화 가능성을 이해하는 데 필수적이다. 이 글은 Go 언어의 메모리 모델 개선 논의를 위한 배경 지식을 제공한다.

https://research.swtch.com/hwmm

#memorymodel #hardware #multiprocessing #concurrency #programminglanguages

research!rsc: Hardware Memory Models (Memory Models, Part 1)

Hacker News 1d ago

Just Fucking Use Go

https://blainsmith.com/articles/just-fucking-use-go/

#HackerNews #GoProgramming #SoftwareDevelopment #TechTalks #ProgrammingLanguages

Just Fucking Use Go - Blain Smith

Vassil Nikolov | Васил Николов 1d ago

It is not for nothing that mathematics (usually) draws a distinction between operations and relations.

Some computer programming languages, not so much.
Here is one thing that can happen, using Python just as a handy example:

>>> 2 == 1 == 0
False
>>> (2 == 1) == 0
True

So, not left-associative.

>>> 0 == 1 == 2
False
>>> 0 == (1 == 2)
True

And not right-associative, either...

What do we call it?
Perhaps "quasi-associative" might fit the bill?
In any case, "anti-associative", "counter-associative", "dissociative", "non-associative", and "pseudo-associative" don't.

Note: the above doesn't happen with irritating silly parentheses ⌫⌫⌫ Lisp's prefix notation.

#CaveatProgrammator
#ComputerProgramming
#ProgrammingLanguages

mocom 1d ago

I think this is pretty neat, and a bit different than most c-style language implementations: any number of initial arguments can be factored out of a group of functions:

https://mocompute.codeberg.page/item/2026/2026-05-08-tess-receiver-blocks.html

#c #programming #programminglanguages #cprogramming #compiler

Tess receiver blocks: reduce visual noise in API headers

Andy Balaam 1d ago

Jez returns for programming language chat!

https://video.infosec.exchange/w/ddh8hoaL2qJj4hvXgS9RUm

Jez returns for programming language chat!

PeerTube

Show thread

innocentzero 2d ago

MMTk porting guide is the prime example of:

How to draw an owl:

- Draw a circle
- Draw the rest of the owl

So, how to port to MMTk?

- Port to NoGC (ensure runtime compiler doesn't shit itself while linking with rust)
- Complete the rest of the port

#mmtk #gc #rust #programminglanguages

ACP Section 2d ago

From 11:00 to 12:00 on Thursday, May 28, the PLSL reading group will discuss "Proofs as Processes" by Samson Abramsky, as well as the first two sections of "Propositions as sessions" by Philip Wadler.

https://plsl.acp.sdu.dk/posts/2025-05-28-proofs-as-processes-propositions-as-sessions/

#PLSL #curryHoward #propositionsAsTypes #concurrency #logic #lambdaCalculus #piCalculus #programmingLanguages #functionalProgramming

Proofs as Processes. Propositions as sessions

In this session, we explore how the propositions-as-types paradigm extends to concurrency

PLSL

sayzard 2d ago

A Grand Challenge for Reliable Coding in the Age of AI Agents
이 논문은 AI 에이전트가 생성하는 코드가 사용자의 의도를 정확히 반영하는지에 대한 근본적인 문제를 다룬다. 비공식적인 자연어 요구사항과 정확한 프로그램 동작 간의 '의도 격차'를 해소하기 위해, 의도를 형식화하여 검증 가능한 명세로 변환하는 것이 핵심 과제로 제시된다. 이를 통해 AI가 생성하는 코드의 신뢰성을 높이고, 다양한 신뢰성 요구에 맞춘 명세 검증 및 상호작용 방식을 연구하는 방향을 제안한다. 또한, 현재 초기 연구 사례들과 함께 향후 연구 과제들을 체계적으로 정리하였다.

https://arxiv.org/abs/2603.17150

#ai #softwareengineering #formalverification #programminglanguages #aicodegeneration

Intent Formalization: A Grand Challenge for Reliable Coding in the Age of AI Agents

Agentic AI systems can now generate code with remarkable fluency, but a fundamental question remains: \emph{does the generated code actually do what the user intended?} The gap between informal natural language requirements and precise program behavior -- the \emph{intent gap} -- has always plagued software engineering, but AI-generated code amplifies it to an unprecedented scale. This article argues that \textbf{intent formalization} -- the translation of informal user intent into a set of checkable formal specifications -- is the key challenge that will determine whether AI makes software more reliable or merely more abundant. Intent formalization offers a tradeoff spectrum suitable to the reliability needs of different contexts: from lightweight tests that disambiguate likely misinterpretations, through full functional specifications for formal verification, to domain-specific languages from which correct code is synthesized automatically. The central bottleneck is \emph{validating specifications}: since there is no oracle for specification correctness other than the user, we need semi-automated metrics that can assess specification quality with or without code, through lightweight user interaction and proxy artifacts such as tests. We survey early research that demonstrates the \emph{potential} of this approach: interactive test-driven formalization that improves program correctness, AI-generated postconditions that catch real-world bugs missed by prior methods, and end-to-end verified pipelines that produce provably correct code from informal specifications. We outline the open research challenges -- scaling beyond benchmarks, achieving compositionality over changes, metrics for validating specifications, handling rich logics, designing human-AI specification interactions -- that define a research agenda spanning AI, programming languages, formal methods, and human-computer interaction.

arXiv.org

WimⓂ️3d ago

Until about 2022, I loved to program in Raku, the language formerly know as Perl 6. (Sadly, since then, genAI has ruined that for me.)

Raku has neat feature called Junctions. A junction is a lazy expression of values of any type combined with Boolean-like operators `|`, `&` and `^`. When an operation is applied to a Junction, it is carried out for each junction element, and the result is the junction of the return values of the operations. You can optionally evaluate a Junction in a Boolean context using `so`.

So you can do things like

my \jj = 1&2;
say so jj; # True
say so (->\x {x-1})( jj ); # False

Back in 2020 I pointed out an issue with Junctions, [The strange case of the greedy junction](https://limited.systems/articles/greedy-junctions/). Junctions are *greedy*, they turn anything they are combined with also into a Junction. This is not always desirable. I proposed an additional operation ("collapse") to undo this behaviour.

In a second post [Reconstructing Raku's Junctions](https://limited.systems/articles/reconstructing-raku-junctions/) I provided a proof for both the observed behaviour and the need for a "collapse" operation, by formalising Junction semantics in terms of polymorphic algebraic data types. I just re-read it and I still think it is very cool.

The `collapse` method never made it into the language (https://github.com/rakudo/rakudo/pull/3944) but my implementation still works.

What I think is neat is that my formalisation lets you implement Junctions in any language.

#programming #programmingLanguages
#rakulang

The strange case of the greedy junction • Wim Vanderbauwhede

An illustration that Raku's junctions are greedy by design, and a proposal.