Issues with language design

[pldis]

By looking at the language syntax so far, it strikes me as something very unreadable at some points. Considering that (AFAIK) you wish this language would be embedded in MC, it is not very user friendly. I have some questions and issues that might clarify the design choices.

1. What languages were the inspiration for Scarpet?
2. What are the principles for the language? Is it supposed to be OO, evented, procedural, functional?
3. What about modularity? So far the naming schemes (with _ and __) feel very primitive and limiting, and the namespace for custom functions will be running out quickly (with global functions like air or put). Did you think about namespacing them? What about relying on magic strings vs constants (_ ~ 'sneaking' vs _ ~ Namespace.sneaking)?
4. List and dicts literals?
5. Do you plan on supporting first class functions? So far it kinda seems like it (with passing expressions into other functions) but the current syntax is super confusing and will cause a lot of problems in the future.
6. About _ "magic variable"... There is a reason magic variables are so rare. They are implicit, confusing and very demanding from a person who reads the code. From what it seems, you are trying to create some kind of Perl-inspired language, but there is a reason why it is pretty much dead nowadays.

[ccfb3ee765a58cae]

I agree with a lot of these concerns. In my opinion, Scarpet should just be an existing language. Gravity would be my favorite choice (it's a very good make-almost-everyone-happy embeddable language) but Javascript, Ruby, Lua, etc. would work fine too.

The conditional and loop syntax where the branches are implicit closures is very strange. Why not just replicate what C-like languages do?

[gnembon]

1. Technically none. I wanted to have functionality or scripting languages (python, perl) in a concise, functional package. Like lisp with operators making it much more bearable.
2. As I said, its a functional language, but with operators, and ';' operator gives it procedural feel as well, which most beginner programmers should be familiar with. In terms of the principles - it should be clean and simple enough, so you look at the program (properly formatted I assume) and know exactly what's going on. Simplicity comes from the fact that entire syntax is only functions and operators. Nothing else. As a bonus - it compiles directly to java functional interfaces. There is a chance that the Java code to do what you program in scarpet would look roughly the same, except from some values boxing and the fact that it essentially resolves to a bunch of lambdas. OO - hell no. evented - not really, but its hard to leave without it in a game and that's something I am working on right now.
3. I already made changes so the game can run separate hosts for each 'modules', meaning you could write a program that would run in isolation from others. Think of it like static private classes in Java. Right now its just one big static space. The use of '_' and '__' is just conventions, successfully adopted in very successful scriping languages like python. I see no problems with that. Regarding namespacing, feels to OO to me - which would make simple scripts unnecessarily complex.I don't have problems with strings. Here everything can resolve to a string.
4. Lists are IMO fully supported at this point. Dicts - maybe, if the use of 'vars' poses a big issue - don't see a problem with adding support for them down the line. Don't have the good name for them though - 'map' is already taken - rightfully so - by the map function. it may stay at python's 'dict's.
5. Not really - that would be tricky to interpret, but I can see clear benefits in them (mainly clarity). For now the good news is the fact that function definitions can be done everywhere, inside other functions as well, and their effect is global (for the script host), so that is a mechanics that can be used to redirect code flow from one place into another.
6. Disagree - for simple operations they provide enough clarity without having too much syntactic sweetness. But when push comes to shove, when I feel its needed, I probably could support some lazy evaluated code, and args. I don't feel like "_" was the nail to perl's coffin.

Regarding scarpet being an existing language - it wouldn't follow the principle of being lean. I bet bedrock's js would have more performance bottlenecks resulting from the fact that it is technically executed on a side and interfaces with the API when it needs something, but I may not correct on that one. Plus I find syntax of things like LUA, very limiting, and confusing with programs with more than 5 statements in them.