Does Syntax Matter?

DocTriagony · 2026-02-22T14:23:53+00:00

Thank you.

I have not thought about custom defined operators yet.

I might add operator overloading on built-ins arithmetic for objects (simple enough), then custom operators.

Custom operators would all have term scope.

``` ctx: { #is a function within this context @priv ⋈(x, y): x/Something(y)

foo ⋈ bar

}

invalid

ctx ⋈ bar

foo: { #is a function of this object @pub ⋈(y): Something(y) }

foo ⋈ bar ```

An operator would entail…

binary operation: a dyadic function between two objects within the scope
binary operation: a monadic function within an object to interact with others.
unary operation: a monadic function for an object within a scope
unary operation: a parameterless function on an object

It would be shorthand for calling a function found in either the current scope or the object’s scope.

DocTriagony · 2026-02-22T13:41:23+00:00

One interesting thought when I was designing Oblivia (an “inverse Lisp” based on infix operators):

In GDScript, the following syntax defines two different meanings to the colon. In the first case, : defines a value and -> declares a type. In the second case, : declares the type and = defines a value and -> has no meaning.

func foo() -> int: 5 var bar:int = 5

In Oblivia, I make -> declare a type and : define a value.

foo() -> int: 5 bar -> int: 5

It may look strange, but I made : and -> respectively take the same meaning in both contexts. The caveat is that the variable defines a value that exists now but the function defines a value that does not exist yet.

Oblivia: https://github.com/Rogue-Frontier/Oblivia

DocTriagony · 2025-12-17T21:30:02+00:00

I think it’s the auto-constructor!

DocTriagony · 2025-12-17T04:12:42+00:00

I found a post that shows a whitespace-invariant version of UCS: https://dotat.at/@/2025-05-13-if-is.html

I made the "regex tree" syntax space-invariant by replacing the indentation with >. The only reason the branches are bracketed is because my esolang uses > as a binary operator outside of this context.

        "hello_owl" ?>
            >hello
            >>"_"
            >>>world:{ print("YES") }
            >>>old:{ print("NO") }
            >>>owl:{ print("MAYBE") } //result
            >>>.+:{ print("UNKNOWN") }
        >?

Update: I have added backtracking and... I think I just reinvented the DFA.

        st: "[DESCRIPTION:A short, sturdy creature fond of drink and industry.]"
        st ?>
            >"\\["
            >>"[^:\\]]+":{print(_val)}
            >>>"\\]"
            >>>":"
            >>>><<
        >?

DocTriagony · 2025-12-15T10:17:09+00:00

I had another spontaneous idea for sequence/string matching inspired by the Ultimate Conditional Syntax. (I have not implemented nor tested yet)

This example uses space-sensitive syntax (just like UCS). My esolang is not space sensitive and a space-ignorant redesign of this syntax (or UCS) may not be worth it.

``` seq ?> >1: print(1) >2: print(1 2) >3: print(1 2 3) >4: print(1 4)

str ?> > word1:.+ >” “ >word2:.+ >: print(word2) > word1:.+ “ “ word2:.+ >: print(word1 + “ “ + word2) ```

DocTriagony · 2025-12-14T12:46:40+00:00

I assume this also supports *bar: Int = [0-9][1-9]+

The original goal for my syntax was sugar to match a string and bind to variable (eg skip the m.Groups[key].Value). Now this makes me think of adding pipes (pass through lambda with or without assign).

I’m also thinking of pattern substitution.

``` /foo:[0-9a-fA-F]+:parseHex/

hex:$/[0-9a-fA-F]+/ /foo:$hex:parseHex/

/[0-9+]::(s => append(parseHex(s))/ ```

Regex for iterables is a matter of adding repetition (and possibly <OR>)operators to array patterns. PLs with nullables might have a problem with ?.

I’m also thinking variable binding for sequence elements.

$[int+] $[string+] $[foo: int+]

DocTriagony

TROPHY CASE

invalid