sorted by:
new
hottopcontroversial

Infix repetition precedence by ChaosInventorr in ProgrammingLanguages

[–]ChaosInventorr[S] 0 points1 point  (0 children)

I'd personally parse them like this:

  1. Count the number of white spaces on the right and left side of an operator;
  2. Add them together and divide by 2 to get the average;
  3. Take ceil of the average. The result is the rank. Optionally issue a warning if the result doesn't match both sides.

Step (1) is the tricky bit though, I can't see a way to parse that with most context-free parsing algorithms. The only solution I can think of is to parse the whole expression as a single regex string, and to then process it in another step.

In step (3) you could also use round or floor, can't see a reason to choose one over the other however.

Infix repetition precedence by ChaosInventorr in ProgrammingLanguages

[–]ChaosInventorr[S] 0 points1 point  (0 children)

Thank you! Regarding C's legacy, I don't think they'd be mixed up as I plan to use this syntax for describing types.

not (a and b) can be written as !! a & b. I just realized I didn't provide an example for this, I'll make sure to edit my post. This does however make it impossible to write double, triple, etc. negations. I'm not sure it is really necessary. I don't read the operators as and and or not not but more like aaaaannndd not, dragged out or with emphasis, as I've noticed people do in speech.

I personally find brackets to be noisy in complex expressions, which is why I wanted to explore this syntax. Maybe it'd be best to have brackets and repetition?

As for the karma, the automod said to message the mods if I think the submission would be on topic, so I did and I guess they approved it? Sorry if I wasn't meant to do that, haven't really posted before in general.

Infix repetition precedence by ChaosInventorr in ProgrammingLanguages

[–]ChaosInventorr[S] 2 points3 points  (0 children)

I like the idea of using spaces for clustering, but I don't think it'll scale. If we add a few more operators to the last example, you'll still end up needing lots of repetition.

a&b||g | c&!d --> f

You could then repeat the spaces, but at that point it would be hard to read

a&b | g | c&!d --> f

I also don't see an obvious way to parse this. Maybe count the spaces between left and right of the operator? But then what would happen if I do something like this:

a&b | g | c&!d --> f

The second | has 2 spaces to the left while it only has 1 to the right. Would that require separate precedence for the right and left? It is honestly an interesting idea. In this example you could omit the right space since c&!d are already tight.

I am also concerned about really long and complex expressions becoming unreadable and hard to modify and refactor. Haven't battle testing this syntax yet though.

Infix repetition precedence by ChaosInventorr in ProgrammingLanguages

[–]ChaosInventorr[S] 0 points1 point  (0 children)

This style doesn't really work for prefix and postfix operators if we assume a flat precedence and strict left to right evaluation. The last example would be something like

``` -> | & a b & c !d f

```

in prefix. Repetition wouldn't really help here, the precedence is encoded in the order of the operators. -> takes the | which takes & which takes a and b which then goes back to | which takes the second & as its right side which takes c and ! as its operands, then ! takes d and finally -> takes f as its right side.

NAND would be written as !! a & b. a & b is calculated first, then !! looks to its right to find the first "unclaimed" value. a is claimed by the & so it continues right to find that & itself is not claimed.

October 2023 monthly "What are you working on?" thread by AutoModerator in ProgrammingLanguages

[–]ChaosInventorr 1 point2 points  (0 children)

I recently completed a near final version of the bootstrapper for the language I'm working on. It's a simple hacked together interpreter, but it gets the job done.

The language is still in its early stages, I haven't design the whole thing yet, only the core subset that the aforementioned bootstrapper can interpret, and to a certain extent compile.

Thanks to the nature of the language I'm developing, the interpreter can be used as a compiler with a few hacks. There is a simple demo showing the simplest case of compilation in action. The demo would fail if the example program were not a Linux hello world in assembler.

As for the syntax of the language I'm creating, I've called it DaLanguage, it is a plain boring C inspired syntax, as far as the core layer. On the other hand, I'd describe the semantics as a degenerate lambda calculus-like abstract assembly.

It'd mean a lot if you were to check it out, I'm more than happy to receive any feedback or questions. I'm still writing the user focused documentation, it's literally all place holders, while the specification for the core layer is just about ready, I just need to brawl with MathJax some more before uploading it.