RFC: Toy Version 0.6.0 Specification

[Ratstail91]

The current spec file now lives here.

[DMClVG]

I have a few gripes with the syntax along with other things, so I would like to suggest a few changes :)

First off, I'm kind of lost on how the language should be used to create structured data types (like objects in JavaScript or tables in Lua). I guess dictionary could sort of be used in the same way, but then you end up throwing out the type system cause most likely you'll have to do dictionary[string, any] for anything slightly complicated. It would be nice that have another data type, or some way to type annotate dictionaries in a more elaborate way.

Also, I argue you should change the var keyword to something else, like let or val. var suggest that the value at hand is variable, when it could also annotated with const. Perhaps you could also introduce a new const keyword for declaring const values, but that would mean that you'd have to avert from putting const in type annotations, which, from what I see, is supposed to be a language feature.

I'm also kinda confused if function arguments are supposed to be contained within parentheses or not. From what I've gathered, print is treated like a separate keyword that also behaves like a function and doesn't require parentheses. It would be awesome if we could also support calling user defined functions without parentheses, as that would be far more consistent and even allow for devs to create DSL languages thanks to such feature.

As for syntax specific issues: I dislike the fact that the condition in while, if and for have to be contained in parentheses. This might be subjective, but they have no purpose in resolving ambiguity or (imo) clarity. Additionally, same could be said with semicolons. However, they are massively important for removing ambiguity (something I ignored in my own language and turned out to be a big mistake), so the best approach would be for the compiler to automatically insert semicolons on each new line and have the dev put them themselves if they wish to write multiple statement in one line.
Could we omit these, it would make for a much more pleasing coding experience (especially important for a scripting language).

One more nitpick, why using for type decls? In other languages, that keyword is used in a wildly different manner.

That's it for the most part. I have no comments on the predefined functions, except for the utter lack of file IO. But I'm not that sure what this language is supposed to be and I'm not going to tell you how it should be used. All I'm doing is throwing my 0.02$

[Ratstail91]

Hey, thanks for your feedback!

You are right about the complex structure types - dictionary might not be enough. I'm considering adding classes or structs, but that's for later.

The var/let idea is a bit "IDK" - I understand your concern about it, but I'd like the language as a whole to be a clean break i.e. it's not weighed down by other language's history. I'll keep this in mind, but for now "var" stays.

Calling functions without parenthesis is an interesting idea, however print is considered a keyword, rather than a function (even though it will eventually be tweakable by the host program). Could you elaborate on a DSL example?

Optional parenthesis for conditionals has been sitting in the back of my mind for a while now - quite a few languages seem to be going that way. The only concern with it is that the end of the conditional requires some kind of delimiter to show when the statement begins. That being said, I've also considered making braces required for all conditional bodies, which would be needed if parenthesis were optional. Considering those two paths, I'd rather go with the more familiar one, but it's definitely a coin toss ATM.

As for semicolons - I'd rather make things explicit rather than implicit - and semicolons just feel nicer to me.

Do you have a better keyword than "using"? Maybe "type"?

Concerning file IO and other missing features, this language is intended to be a script-based supplement for games - Little moddable snippets of code. However, if the host program needs file IO in the script, it'd likely be imported as a library feature. I haven't detailed a "standard library" yet, which will likely be a pluggable extension to the main engine.

Again, I really appreciate the feedback, thank you!

[DMClVG]

I don't mind keeping var at all. It's just a little thing I thought I might point out. Your point is also understandable; no one wants to follow these pesky little rules when making their own language :)

And because you asked, here's an example for a DSL (in lua):

-- Example taken from https://leafo.net/guides/dsl-in-lua.html
html {
  body {
    h1 "Welcome to my Lua site",
    a {
      href = "http://leafo.net",
      "Go home"
    }
  }
}

Here, every keyword is actually a ordinary lua function that takes a single argument. For instance, html and body take in a Lua table, h1 a single string, etc. and they each return some value that finally make up the DOM tree.

It's obviously not real DSL in the sense that it doesn't affect the AST the same way macros do, but it is similar, although much less powerful.
For concrete examples there's Lpeg (makes heavy use of operator overloading, so maybe not the best example) and Lapis (its more often than not used with MoonScript, a dialect compiled to and interchangeable with Lua, because its more lax when it comes to when or when not parentheses are necessary + it's got many other nice little features that I honestly think other languages should model after)

Ultimately, I'll admit it's not really that necessary, but it is something worth experiment with.

type sounds like a notable contender for replacing using. It will more closely follow the pattern var x = <expr> except its for declaring a new type a not a new var, whereas using doesn't really strike me in this way imo

For the last bit: maybe the language could have a separate runtime for free standing applications, sort of like what JavaScript has with Node/Deno/Bun.
For everything that is fundamental or unchanging in the language it could always stay in the "stdlib" (think of insert, concat, sort, copy..), and for anything beyond that (File IO, Sockets, etc.) will need to be implemented on a per application basis (with enableable extensions for ease of integration sake). I think its most logical this way, as the host almost certainly doesn't want a malicious scripts (or mods) to get access to the file system when its not supposed to. But ig I'm basically just reiterating what you said.

Again I'm only giving my opinion, but by all means you're welcome ^ ^

P.S. I'm fairly certain the methods in the example structure are supposed to be opened with func and not fn lol

[Ratstail91]

I see, that DSL idea is interesting, but I'll leave it for now.

type it is, then.

The runtime will be called toybox, most likely - and yeah, the plan is pretty much what you said.

Thanks, I actually really appreciate your input! It shows that this project does have legs lol.

[Ratstail91]

I've tweaked the intent of import and export - they are now intended only to interface with the host program - and there's currently no mechanism for running external .toy files. This functionality might be added with a utility library.

[Ratstail91]

Proposition: Rather than having built-in types, the dot operator and slice notation can simply be syntactic sugar for function calls:

import "standard";

print dict.length(); //implemented as length(this: [any, any])

import "standard";

print arr[42]; //implemented as _get(this: [any], first: any, second: any, step: any)

This allows for method chaining, as well as extension methods.