benhj / jasl Goto Github PK

string_length(s, a);

In the following statement,

fn:int myReturnable() -> toReturn {

    return toReturn;
}

we don't need 'return toReturn;' since this is implicit in the '->toReturn' bit.

list(mylist, [a b c d e f g]);

Currently all variables are global. Which is a bit crap.

Since string(s, "hello"); is allowed should also allow:

int(s, 5);
double(x, 1.1);

etc.

list_get_token (1, [hello world]) -> token;
echo_nl token;

Should print out "world".

string "there" -> str;
list_token_index (str, [hello there]) -> in;
echo_nl in;

should print out 1.

We might do something like

load filesystem;

That will load a bunch of commands associated with filesystem operations.

E.g.

input(s, "Please input something: ");

Storing answer in string 's'.

Switch internal representation from int to int64_t.

E.g.

integer 5 -> a;
decimal 5.1 -> a;

is currently allowed. Printing out the value of a using echo will further print out 5 since the set of integers are searched in precedence of the set of decimals.

Something like:

matches (string, regex) -> yes;

array:int(10) -> a;
length a -> alength;

etc.

string_has_token("hello, there", [there], result);

result == true;

Language syntax is far too c like. For variables how about the following kind of syntax:

integer 5->n;
decimal 3.14->d;
string [hello world!]->s;

Where file is a string indicating the absolute path, read in token by token:

for_word w in file {

}

Read in char by char:

for_char c in file {

}

Read in byte by bytes (will assume binary mode)

for_byte b in file {

}

The latter example will depend on the byte type having been implemented.

More API ideas

file_read_strings path -> strings;
file_read_bytes path -> bytes;
file_read_text path -> str;
file_list path -> strings;

Instead of

array:int(5) -> A;

we could do

ints (5) -> A;

instead.

E.g.

string_append
string_reverse

etc.

Rather than always setting to command-specific error string.

system(command);

where command is a string

At some point it broke, possibly with the introduction of the return stack

At the moment a structure is generated holding information pertaining to a parsed statement. That structure is then used by a given command to bring about certain functionality. I think it would be better to have each command execute as soon as the command is parsed. This ought to drastically speed things up.

There are a lot of redundant grammar rules in the parsing engine right now. Several can be condensed down to one, I think.

An array of bytes to a string representation:

array:byte(10) -> bytes;
///...
string bytes -> bytesToString;

A string to an array of bytes:

string "just a test string" -> str;
array:bytes str -> bytes;

to_int(s, a);
to_decimal(s, a);
etc.

integer(a, 1);

As in "store the integer 1 in variable with name 'a'" should be:

integer(1, a);
decimal(2.2, b);
string("Hello", c);

etc...

This will be consistent with string_length("Hello", length);

For file manipulation

Rather than:

OptionalDouble ScopedVarCache::getDouble(std::string const &key)

do:

bool ScopedVarCache::getDouble(std::string const &key, double &value)

In start function allow:

args(0, s); // put arg 0 in to string s
to_int(s, a); // will convert string s to an integer storing result in a

See for example queens.jasl as to why this would be advantageous