Hacker Newsnew | past | comments | ask | show | jobs | submit | pmcgoron's commentslogin

If you want to peer into an alternative reality / funhouse mirror of programming terms, you should look at ALGOL 68. For instance, types are called "modes".

https://jemarch.net/a68-jargon/

(There are also "incestuous unions", which is the actual term used in the spec.)


Huh - R has a concept of “mode” that overlaps and complements “type”… but then again R also a very funhouse mix of terminology.

https://rstudio.github.io/r-manuals/r-lang/Objects.html#inde...


From the docs, an incestuous union is the equivalent of a packed union in C? Well, you gotta be packing' to be incestuous :D

Would SectorLISP (https://justine.lol/sectorlisp2/) count? It can run the LISP 1.5 metacircular evaluator.

From John Cowan:

TAGBODY doesn't actually require continuations, delimited or undelimited, just proper tail calling. A macro can rewrite each section of the TAGBODY into a procedure nested within a `let` that tail-calls its successor, and the body of the `let` tail-calls the first procedure. (GO tag) is then equivalent to just (tag). This is a great way of doing state machines. Chicken has a tagbody egg, I think.


As someone who writes a lot of Scheme, I agree that the math syntax is not good. There have been proposals to add infix expressions (https://srfi.schemers.org/srfi-105/) but nobody seems to want them, or can agree on specifics.

However, code that is mostly function calls is fine for me, since those would have parentheses anyways in C++/Rust/whatever. In that case it makes the language more regular, which is nice for writing macros.

I'd be curious to hear your opinion on wisp (https://srfi.schemers.org/srfi-119/srfi-119.html) and the Readable project (https://srfi.schemers.org/srfi-110/srfi-110.html) which are significant indentation syntaxes for Lisp languages that are still closely related to the AST and allow for easy macro writing.


Earlier last year, I "quietly" introduced an infix support macro into TXR Lisp.

I devised a well-crafted macro expansion hooking mechanism (public, documented) in support of it.

It works by creating a lexical contour in which infix expressions are recognized without being delimited in any way (no curly brace read syntax translating to a special representation or anything), and transformed to ordinary Lisp.

A translation of the FFT routine from Numerical Recipes in C appears among the infix test cases:

https://www.kylheku.com/cgit/txr/tree/tests/012/infix.tl?id=...

The entire body is wrapped in the (ifx ...) macro and then inside it you can do things like (while (x < 2) ...).

In completing this work, I have introduced an innovation to operator precedence parsing, the "Precedence Demotion Rule" which allows certain kinds of expressions to be written intuitively without parentheses.

Everything is documented in detail:

https://www.nongnu.org/txr/txr-manpage.html#N-BEB6083E


Wisp looks pretty good! I'd have to try it (or see longer examples) to know for sure but it's exactly the sort of thing I meant.

1. I don't know much about HM systems mathematically, but how do the effect handlers interact with type inference? I thought there was some issues with automatic inference there.

2. The macros examples on the website don't show binding situations. Are the macro hygienic like in Scheme?

3. Why the choice of [] over ()?


good questions

1. effects are tracked in the type system as row types, so they compose with HM inference pretty naturally. the tricky part is effect polymorphism. Loon handles that similarly to how koka does it, with row polymorphism. no ambiguity issues so far but idk

2. yes, macros are hygienic! documenting some binding situations would make a great first PR :)

3. easier to type!


I guess I'll have to read more about effect handling systems, I'm very much out of my element there.

> yes, macros are hygienic!

I'm glad. Too many lisps chicken out and don't add them.

> easier to type!

Fair enough.

This seems very interesting, I will check it out.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: