r/ProgrammingLanguages 3d ago

Requesting criticism Do you find this syntax readable

https://github.com/ksksidjjejs8/Snjzjsnd/blob/main/exm%20(3).txt#L2

I feel like curly braces aren't enough alone for organizing code. I also want it to have natural steps that induce some blank lines after completion of the step. like with assembly. my main concern is readability and self documentation. It will mainly be for programming on windows. The 'thunk' libraries are mostly wrappers for tedious apis like writeconsole. I plan to add more for things like graphics and math in addition to the planned window/console/file. I see 'thunks' in ghidra so its a reference to them being wrappers. It will also support normal win32 imports.

thankz

edit 1: I have read all feedback so far. the language is case insensitive. for branch{}endbranch and alias.name{}end alias.name the idea was to make it a little more clear which curly brace belongs to what if someone had a bunch of nested stuff. with that being said, it seems the consensus is that the syntax is awkaward while readable, there are still some large wrinkles.

because of your feedback, i will 1. Allow the pattern "name{}end name"," name end name", and/or" {}". 2. Make the language case insensitive 3. Make whitespace completely optional 4. Sinilar to the first thing, allow parameters for functions to be entered either on seperate lines or within parenthesis and seperated by commas (but not both within the same function) 5. allow %/n% within a string, or a %hexConstant% for other characters instead of 'newline' on a seperate line.

i am still accepting feedback, and i appreciate those who have responded.

0 Upvotes

12 comments sorted by

17

u/Norphesius 3d ago

That's a lot of empty space, 48/143 (33%) of the lines in that file are blank. Stretching things out vertically that much made it harder to follow the flow of the program and sub structures. The blank lines make it harder to line up where indented blocks start/end. The tab size was also excessively large, but I assume that's a formatting issue.

I think the bigger problem is that the structures seem inconsistent. It seems like generally you're doing a pascal-style begin/end thing for blocks, but some blocks still apparently need curly braces, and some places like the imports at the top don't need them? The indentation following what I assume are procedure invocations (e.g. WriteToConsole, Convert) is also hard to follow. I'm not sure what parts are even actually arguments to the procedure, since some of them seem more like actual logic than arguments being passed in.

Overall I think this code is far too vertically spaced out. The program seems to be a very simple one, yet it's difficult to figure out what it does at a glance because it's so sparse, exacerbated by the language seemingly having some unconventional features most won't have an intuition for.

12

u/Financial-Flan1682 3d ago edited 2d ago

So the perfect example of why people don't do this is branch{ }end branch. It's just...awkward. You should do one or the other. Either ALGOL/Pascal-style or C style. Not both.

7

u/jcastroarnaud 3d ago

It is readable. But the syntax and examples are a bit strange.

To start with, the indentation is all over the place, and almost no one uses 8-space indents these days. Make sure that your lexer treats tabs/spaces consistently. I suggest disallowing tabs, or autoconvert them to spaces.

Must "MAIN", "PROC", "ENDP", "END" be uppercase? Is there a convention for casing of variable names? BTW, where/how variables are declared? What "Clean" and "Exit" do?

The "branch{" ... "}endbranch", and similar control structures, have redundant information. I suggest going the way of Pascal, bash, Visual Basic and PL/SQL, by using only the keywords and omit the braces.

The arguments to WriteToConsole feel inconsistent to me. On one side, a very loaded string delimiter ("..."), which appears at first glance the only argument of the function; on the other side, a newline keyword, unadorned. I suggest dropping the parentheses, and use only the quotes for strings (as most languages do). Code formatting takes care of the rest. Here is one of your examples, reformatted:

WriteToConsole "Correct!" newline "Do you want to play again? [Y/N]: "

1

u/NoSubject8453 3d ago

No, they dont need to be. i should have specified that. i agree that the indentation is inconsistent, and i will make it optional. i would be removing whitespace and moving to all lowercase while converting to assembly.

variable types are regular assembly sized registers (byte to zmmword), then buffer is sort of 'raw' and can be treated however youd want but by default would be bytes. im also considering sub-sized types, for example nibbles, bits, or other oddly sized amounts in an array like structure. mentioning and creating a variable are the same format, the type followed by a . and a name.

clean would close things like file handles, destroy menus, windows, bruahes, etc, and handle other os specific quirks. exit restores the stack to its original state then does a ret to mark the end of the program. it is more of a convention (like marking program ending conditions, or the actual end of the program) than a requirement as it may not actually clean if no such things are open, and would do whatever is required to end the program gracefully if or if not present.

i will add an option for one line functions or each parameter on seperate lines, and something like %/n% for inserting newlines and other chars directly into strings as id do for things like errors or whatever %s and %d are considered from c.

5

u/L8_4_Dinner (Ⓧ Ecstasy/XVM) 3d ago

Brings me back to the languages of the 1960s. So readable? Sure, in a COBOL / Fortran / Algol way. I'm just not sure that's a compliment, at least not after say 1975 or so.

5

u/brat3108 3d ago

It is all over the place. It seems that braces, begin-end and significant indentation all seem to be used. Indentation is inconsistent.

Are AllocateMemory and WriteToConsole both function calls? If so, why does one need parentheses but not the other? If not, then what is going on?

What is for, and why it alone seems to need a trailing colon? Is this case-sensitive or not?

Maybe the same example in a known syntax style would have helped, but it still is a poor syntax.

I agree that braces are too insignificant for delimiting multi-line code. In that case replace them, don't just augment!

3

u/NoSubject8453 3d ago

Per AutoModerator's request I hereby confirm that this this project did not use an LLM as a part of the development process.

3

u/GoblinsGym 3d ago

I'd rather have semantic white space... Readability is alive and well.

1

u/renozyx 3d ago

I think you should create a few example with the different possibilites instead of asking people to judge on abstract rules.

If you really want to have name{...}end name, the 'end ' will be repeated a lot of time, so I'd suggest doing it like html and using name{...}/name.

1

u/dcbst 3d ago

Take a look at the Ada language syntax, it was specifically designed to be readable and maintainable. It does away with curly brackets completely and uses end tokens, if -> end if, loop -> end loop, etc.

1

u/bl4nkSl8 3d ago

I think less indentation and less implicit functionality (perhaps comments to explain syntax features that aren't common) would help

1

u/Feldspar_of_sun 2h ago

Definitely not. I find it much more uncomfortable to have to move my eyes back and forth when reading lines than up and down (personally at least)