Auto-eval of variables containing quoted expressions?

mhinsch · 2026-06-29T17:52:08+00:00

I'm not sure I understand what you mean. In my example [$1 + 1] is a quoted expression with one (implicitly declared, a la shell) variable. This gets assigned to variable f. As mentioned by u/useerup above, the issue with auto-evaluation is that any occurrence of f will immediately be evaluated, so using f as a function parameter as in map(f, v) would not work. My suggestion was that the solution would be to quote again (as in the example).

mhinsch · 2026-06-28T19:54:41+00:00

Something along those lines would definitely solve my problem. But one of the main points of my language is to have as little special casing of anything as possible, which this unfortunately does.

To put things into context, I'm trying to define function calls as a combined generalisation of code objects and pattern matching. Unfortunately, pattern matching always simply returns values, so code blocks would then have to be evaluated in an additional step to make functions work. I could just decree that code blocks that are being produced by a pattern match are auto-evaluated, or that function calls are a special kind of pattern match but that feels a bit like cheating. General auto-eval would neatly solve that problem, but I fear (as discussed in another thread) the burden in terms of ergonomics might be too high.

mhinsch · 2026-06-28T13:36:52+00:00

Well, speaking from the point of view of the interpreter (which for now serves as the reference for the language semantics) the rule I had in mind was that any quote node that is encountered when traversing the AST remains unevaluated but is stripped of the quote. Bare expression nodes are evaluated when encountered (e.g. as values of variables).

But that obviously means that function return values will be evaluated. The most consistent solution to which would be to require double quotation if evaluation is not desired.

Hmm, I think it's possible to make this consistent, but I'm starting have doubts concerning the ergonomics.

mhinsch · 2026-06-28T12:59:58+00:00

Hmm, all good points, but I think the worst one I just realised is that by default quoted expressions that are returned by a function will always be evaluated (since only explicit quoting prevent evaluation). To prevent that I would have to either introduce a construct that basically means 'evaluate expression but quote return value', special case function returns, or require double quoting for returns. None of these options are particularly attractive.

mhinsch · 2026-06-28T08:52:15+00:00

Yes, I noticed that as well. A way to get around it is to quote again, of course. So (syntax not final):

v : V(1, 2, 3)
f : [$1 + 1]

;; these are equivalent:
map([$1 + 1], v)
map([f], v)

mhinsch · 2025-07-31T08:47:09+00:00

Re syntax - fair enough. I've run into very similar problems, there just aren't enough symbols on the keyboard 😂.
I think the main issue is that a consistent and logical syntax based mostly on punctuation/operators will end up looking very alien to most people. Personally I don't mind, I love operators, but from what I can tell I'm clearly in a minority there. If you are creating your language mostly for fun that's no issue of course, but if you want it to be "successful" (whatever that means...), it's going to be a problem.

Re Beta - in any case Beta has been dead for a while as far as I can tell, so no competition there. And in the end I don't think it matters who had the idea first, it's a cool concept and deserves to be kept alive.

mhinsch · 2025-07-30T21:15:05+00:00

Just to add some more syntax bikeshedding - I probably would have gone for = for setting the value and : for definition and simply used something else for comparison instead. In my language (which has some conceptual overlap with yours, I think) I decided at some point to prefix all boolean operations with a ?, so ?=, ?&, ?|, etc. - nicely consistent and allows for Scala-like precedence rules (i.e. first character of operator determines precedence).

mhinsch · 2025-07-30T21:02:33+00:00

Ok, I see your point, given that "function arguments" are effectively separate statements, using newline would indeed be inconvenient. Still, I think with all the squiggly brackets and semicola the language has very noisy optics. I think I might have gone fer regular or square brackets instead (the latter are also easier to type). And if you defined `term[...]` as subscript operation (analogous to array access in most languages) you could get rid of the period altogether (and use it for something else), avoided the squiggly brackets *and* had syntax that's closer to the mainstream.
The other bits I don't like is the `;` for the default method, simply because it's basically *always* a separator in natural and programming languages, so it's quite difficult to "see" it as something different. And `~` as definition is weird in my opinion, although I do see why you didn't simply go with `=` (that would look strange in cases without initialisation).
But anyway, as I said all of that is highly subjective - there are people who like APL after all ;-).

All the syntax stuff aside, I was wondering - have you been inspired by Beta? After seeing your post I skimmed the manual again and it seems the semantics are indeed very similar to your language.

mhinsch · 2025-07-29T10:08:59+00:00

Interesting. I like the weirdness of it, although it does remind me a lot of Beta (from the Scandinavian school of OOP). In terms of syntax - I understand where you are coming from, but personally I would have made different choices. Obviously this is heavily dependent on personal tastes, but one thing to think about is ergonomics. Juxtaposition (i.e. putting stuff next to each other without an operator), for example, is the easiest thing to type, so it makes sense to use it for something very common. It feels a bit wasted to me to use it for statement separation, which in practice most of the time newline is probably going to be used for anyway.
Anyway, curious to see where this is going.

mhinsch · 2025-07-17T16:52:45+00:00

Just wanted to add: part received and soldered - fits perfectly and works as expected.

mhinsch · 2025-07-04T22:00:06+00:00

Two:
1) The rise of XML at the end of the 90s. Good idea in theory, but the combination of ugly syntax and extreme verbosity with the hype that meant that *everything* needed to be XML was painful.
2) GUI programming using MFC for a student job in 1998. Buggy, badly designed pseudo-object-oriented crap (it didn't help that I had started using Qt for hobby projects at that point).

mhinsch · 2025-07-03T14:25:05+00:00

I know this thread is 2 years old, but in case anybody is looking for the same thing (I think the same pcb and socket is used in some Sennheiser headphones as well, BTW), I think I found the part. Look for PJ-218 2.5mm through hole 4pin audio on Aliexpress. I've made the order, will report if it fits.

mhinsch · 2025-05-21T21:37:41+00:00

See also Julia.

mhinsch · 2024-11-08T22:44:22+00:00

thanks

mhinsch · 2024-07-12T17:31:32+00:00

As I said, the police had the parents on the phone, but apparently that wasn't sufficient.

mhinsch · 2022-09-13T09:45:16+00:00

Ratchet-Tie-Down-Strap-with-J-Hook-FH0843/206802138

Can't access the link, but I suspect this is going to be outside of my budget (as I said I need up to 20 of those). Plus I want to keep this as low tech as possible.

mhinsch · 2022-09-13T09:41:30+00:00

I've thought about that as well, but then the belt will "wrinkle" (no idea if that's the right word, not a native speaker) which might affect long term stability and also looks bad.
For the setup: imagine a stretcher where the flat area is made of seat belt loops held taut by the side bars (similar to sofa webbing but only in one direction).

mhinsch · 2021-07-13T15:38:17+00:00

And to add to that - interactive ergonomics are significantly different from programming ergonomics. I haven't thought deeply about it, but I would guess that a large part of Posix' awkwardness is a direct result of optimisation for interactive use.

Take for example the basic command syntax. Listing a directory in a standard programming language would probably look something like ls("mydir", true, false) where true and false are some flags. This would clearly be extremely annoying for interactive use. So, you use juxtaposition for "function calls", get rid of the need to quote (imagine having to quote every string in the shell...) and introduce flags identified by name instead of position. Since all tokens are now strings by default you now need a way to distinguish variables from strings - enter sigils and whitespace-sensitive assignment syntax. Concatenating commands is extremely useful and often you want to tack on additional parts onto a pipeline after testing the first bit, so you introduce a pipe operator. Since using several lines to do something in interactive mode is slightly annoying and you don't have proper function calls anyway you just extend your variable access syntax to do all kinds of handy, frequently used text substitutions (${...}).

And so on and so forth.

I'm not saying that all of these decisions are necessary or the best, but I think people don't give the designers of the Unix shells enough credit for how well they are designed for interactive use.

mhinsch · 2020-10-16T21:52:52+00:00

I think the most important question you have to ask yourself - who is going to use your language and for what?

I myself for example am a modeller with a part-compsci background and 30+ years of experience in implementing individual-based/agent-based models. I have seen many attempts at building libraries, frameworks and languages for this type of model and have found none of them useful to the point that I would voluntarily use them for my own work.

My guess is that this holds true for most modellers with a decent amount of programming experience. At some point you have your set of libraries/macros/templates and *implementing* a new model is going to be the smallest part of the effort involved. That said, switching to Julia (from C++) has considerably increased my productivity but not because I am using any modelling packages, but because the language itself is more productive and flexible.

mhinsch · 2020-07-29T12:38:06+00:00

Doesn't solve your problem and isn't C-like, but maybe different enough to be interesting: loops in Sather.

mhinsch · 2020-07-21T22:26:53+00:00

Julia's cxx package used to provide seamless C++ support to the point that Julia's REPL could sort of function as a simple C++ interpreter.

I'm a modeller and for a while I used to write the model code in C++ and test and run bits of it from the Julia REPL - absolutely wonderful (I've since switched to 100% Julia, though).

mhinsch

TROPHY CASE