no, but I do have lab.antlr.org

ah ure doing that

i thought you were asking about how to get it to generate parsers

nope lol

syntax is like ebnf

so I see

you have a start rule that consumes the entire input

actually wait you need to do the lexer first

its like ebnf + regex

im assuming you know lexers and parsers and that goodness

yes

so lexer rules are like regex

STRING: '"' .* '"';

indentation looks annoying, maybe I should do curly-brace stuff instead

or do/end :p

they start with an uppercase letter, screaming snake case is convention for lexer rules

@Ginger here are a bunch of grammars for a bunch of langs

yean indentation will be annoying to parse

time to steal from the examples!

heres python

@Ginger yeah i do that all the time

in fact the type grammar for rol was stolen from kotlin :P

lol

@RydwolfPrograms Based on github.com/Radvylf/npsp2/blob/main/chat.rs, Rust syntax looks like a mashup of C++, Python, and Haskell. Overall, I don't hate it. The thing I like least is the complicated types like Result<(), Box<dyn std::error::Error + Send + Sync>> which (to my untrained eye) are confusing and hard to read. (Maybe it would help if that type were given an alias? I notice you use it several times.)

Haskell syntax is low on delimiters, which is tricky to read at first but looks really clean once you get used to it. E.g. Maybe [Event] instead of Option<Vec<Event>>, or Map.Map String RoomData instead of HashMap<String, RoomData>. (You can always add parentheses to disambiguate if you want to.)

Also, personal preference, but I really dislike C++ style :: for packages/modules/namespaces/whatever. I think . looks much nicer.

@Ginger pythons grammar is actually very messy

so I see lol

@pxeger Moderately low-level. Like, a step above Rust.

@Seggan Well I'm 100% making a distinction non-syntax-wise

Requiring all arrays to be vectors is unnecessary

should Rabbit use let/var/whatever?

Yes

which one? I like let

I'm actually debating with myself right now about which one to use for Cuprous

And whether or not to require mut for mutable ones

@Ginger whatever ;P

The options are: let, let/let mut, var, const/var, val/var, [type], [type]/mut [type]

Not a fan of var/val since they're only a letter off

^

@RydwolfPrograms What's the difference between the two semantically?

Which two

There are two concepts that you're deciding on names for. What are those two concepts?

For the paired ones the left is immutable vars and the right is mutable ones

For the non-paired ones I'd just not have a mutability distinction

The right two are C-style type name = value declarations

The rest would be keyword name: type = value or keyword type name = value or something

Is immutable like actually immutable, or is it like const in JavaScript where you can't assign a new value but you can change the existing value?

Actually immutable

Good

Also static could be a possibility in place of const, to create a three-level distinction: true constants (known at compile time), immutable variables, and mutable variables

const/imm/var maybe

I'm not a fan of mut. (But is the point that values are immutable by default, to force the programmer to think about whether they really need this to be mutable?)

Yeah. I'm not sure how I feel about that tho. I do want the lang to encourage good programming practices of course, but then again, I also want to focus on making it quick to write and iterate on

And having to strategize in advance about mutability could get in the way of that

Hmm

This was another fun puzzle.

I kinda don't like let (for mostly idiosyncratic and dumb reasons), tho I feel it's probably the best choice

@RydwolfPrograms I'd say the same logic applies even more so to the distinction between compile-time constants and immutable variables. Seems like an implementation issue that I, the programmer, don't want to have to think about.

@Seggan how did you keep Rol from screaming about extraneous spaces?

And here's the accompanying Cracking the Cryptic Video: Normal Sudoku SIZE Does Not Apply

I could do con for constants I guess

blech

What's wrong with const?

^

What are we discussing?

It's longer. People could easily just get lazy and use var instead, which defeats the point of a distinction

@DLosc (if you're going to have a keyword with that meaning)

What are y'all's opinions on C-style type name = value?

@RydwolfPrograms Pretty positive. It's a syntax I'm used to.

I guess one issue is no type inference

Unless you did _ x = ... all the time which is kinda weird

And I plan on relying pretty heavily on type inference

@RydwolfPrograms C++ uses auto x for this, I think

Yeah, but I feel like that sort of makes type inference an exception rather than the default

When ideally you would practically never need to give a type to a variable explicitly

@RydwolfPrograms Maybe var x = value is the default, and if you have to define a variable without giving it an initial value, then you use type x?

Possibly, yeah

oh

I guess the other problem with const is if you're going to use it in contexts where it's not actually a constant because it depends on other values. Like function(list) { const length = list.length; ... }. I think Scala does that a lot with val, which is fine, but using const in that context doesn't really make sense to me.

Yeah, that's why I was considering static or imm

In that case I think I would prefer let

Might be some Lisp influence showing, TBH

So I think my answer would end up being

var x = 42        # For variables with initial values
const PI = 3.14   # For actual constants
let y = x + 100   # For immutable values

If you wanted to ditch const and just have let, I wouldn't be too bothered.

And for variables without initial values (if that's even allowed), I'm not sure between int x, var int x, and var x : int

int x is the cleanest, but it doesn't feel like it fits with the rest of the syntax.

TIL JavaScript has do... while loops

@RydwolfPrograms thats a plus for me

@Ginger in the lexer add WS: [ /r] -> skip;

the lexer will swallow spaces not inside any other tokens

@Seggan I'm honestly curious: Why?

mfw I reload the antlr lab and delete an hour of work on my grammar

I am so stupid

@DLosc they look similar enough that when quickly scanning i see that theyre both var decls

Hm, okay

@Ginger when i used idle i had a habit of pressing ctrl+s every 5 seconds :P

var is my ideal variable decleration keyword. const var I prefer over just const.

CMC: Play Bad Apple

@ATaco That exhibits the "immutable variables are harder to create so nobody will use them" issue even worse

It should be the other way around if there's a keyword to indicate mutability; it should take an extra keyword to make something mutable rather than take that away

I didn't say it was better, I said it's my ideal.

Ideal means "most better" doesn't it :p

That sounds like rust, I'm scared.

My requirements in a programming language are far beyond my own understanding.

Isn't an Immutable Variable an Oxymoron anyway?

The value can still vary even if it's only ever one thing each time it's declared

To force consious thought in defining mutables, one could use the pairing, int: x vs mutable int: x

The let keyword even makes a bit more sense than var in this instance.

@ATaco I;d probably go with mut int not mutable int, but yeah

That;s actually one of the possibilities I'd initially suggested I think

@RydwolfPrograms yeah thats the java problemo

I think I'm leaning "no mutability distinction in syntax"

Just for speed of writing

Bad suggestion: Mutabiltiy requires a decorator.

[Mutable] let x = 3;

i love this typing userscript

I should do something like Fortran's type assumption based on alphabet. Any variables starting with i through n are mutable, the rest aren't

...

It's important to not let the compiler guess for every case, as one of the benefits of explicitely definined immutability is forcing the programmer to not mutate it.

(*(&stdlib::mut)->declare_mut) x = 3

@ATaco Meh, I don't really buy into that

Unless you work somewhere with someone who sneaks into the office after hours to mutate your variables

Well, multiple programmers frequently work on the same project.

Accidentally assigning to something that genuinely shouldn't have been assigned to is pretty rare, especially if assignment is a statement

And I wouldn't trust myself either....

Though which applicants are you using finding implicit mutability a problem?

Wdym?

The lazy ignoring of the const keyword doesn't affect most applications, does it?

I guess not

But it's not super useful to have if people don't use it much

In cases where a RAM is much more limited than ROM, it makese sense, but anyone writing code for them should be aware of that limitation.

It doesn't affect finished product, but it certainly affects code under development

Also immutable values go to RAM if they're computed at runtime

^

It has basically no effect on anything performance wise, the compiler can just optimize out actual constants into actual constant

In which case, I suppose guessing if a declared mutable variable is secretly a constant can be detected anyway, whilst preserving a const keyword for the programme's sanity.

It can be detected, yes

In my experience with Rust, declaring a variable as mut and not mutating it was an actual bug 99% of the time (because I did intend to mutate it somewhere but forgot), and Rust's unused_mut warnings saved me a ton

Rust looks like amazing for programming larger projects, but I am far too into the c-like mentality to switch over and learn Rust's syntax.

rust syntax is pretty c-like in the broad scheme of things :P

or i guess more c-like-like

I started with C/C++ but learning Rust made me kinda unlearn them

Also yeah, Rust is a C-like but more correctly designed

I think I'm just gonna go with let and let mut for now

Many of the rust specific keywords and syntax confuse and scare me. See: impl.

Maybe I'll come across something later that I prefer, but for now it seems like the best option

@ATaco traits and associated functions are really intuitive

it's like oop minus the oriented and object parts

^

If you forget what you know about OOP most of it's practically trivial

I do think it's hard to find good high level explanations of Rust's OOP-y aspects tho

It took me ages to get a good big picture of structs, enums, traits, impl arguments and dyn types, where, etc.

IMO programming language tutorials tend to take the wrong approach. Don't teach me a bunch of little things one at a time, push me straight into the cold water with a syntax cheatsheet and a high level description of the language's design, then fill in details from there

(tutorial for people who already know one or more langs, that is)

That's why my go-to for learning a language is modifying existing code.

LDQ: Should my generics look like Box<string>, Box(string), or Box string?

I'm thinking Box string with parentheses being optional, but required for generics with multiple types (so TwoCollections(string, [i64]) for example)

Nah, not sure I want to implement a whole prefix lang just for parsing generics :p

Ooh stack based generics

The name of a type pushes the type to the stack. Generics pop some types. $ swaps the top two types, and # discards the top one

And % duplicates

_ for discard and : for dup

string % TwoCollections % [i64] $ TwoCollections (*, *)

At least have some consistency with stack language traditions :p

Nah, can't have any ambiguity in this system, which is currently entirely devoid of irrational choices like that :p

@RydwolfPrograms I can't help but think this looks like a scala dependency declaration lol

*sbt

@RydwolfPrograms it’s actually pretty easy to parse

@user which is basically the de facto official package manager

I like Box<string> too much from JS and C#

@lyxal :(

@ATaco the ambiguity is annoying tho

And principle of least astonishment is a good one to follow...

You need turbofish like rust

If you use <>

Box of string

@ATaco It's ugly tho...and hard to type, and some (typically lightweight in-browser) text editors don't do bracket matching for <>

Optional of int

Square brackets also feel kind of right, like a child of indexing.

Yeah true

i feel like generics should look like function calls in general

@RydwolfPrograms unironically a good idea

String Int HashMap Int String HashMap 2 Tuple

(String Int HashMap) (Int String HashMap) 2 Tuple looks good to me

Well that's just boring old postfix. It doesn't get interesting until you add adverbs and stack manipulation

What if you could vectorize generics onto collection types

Once your generics are 3 deep it might be time to abstract at some level.

@RydwolfPrograms except the Tuple has to be told how many arguments to take :P

^

Ooh...there should be a special case of two-type generics that uses -> for its syntax

For lambdas and hashmaps

Just add Twople and Threeple as sugar types.

HashMap string -> i64 or Fn ((i64, i64) -> bool), for example

(not sure if the surrounding parens would be required)

People for 70 billion Tuple

70 billion? Did I fall asleep for a few generations?

Did you mean: 8 Billion Tuple

oops

base 1000 vs. base 10000 strikes again

also isn't it crazy you could store the full name* of every human on earth on a hard drive that's small by today's standards