Note: this is not referring to Kitten’s interactive mode (REPL) but rather how a programmer uses the compiler on the command line.
Ideally, I’d like for the compiler to adhere to a few rules:
To reduce assumptions about the environment, it should not implicitly use any Kitten-specific environment variables or configuration files. For example, LANG and EDITOR are fine, but KITTEN_PATH is not.
Command-line flags should be Unix-like and reasonably familiar to people who use other compilers, to reduce the chance of mixing up flags.
The interface should be flexible and easily extended, piggybacking as much as possible on the existing language infrastructure.
We’re good on number 1 in the new compiler (the old one only used KITTEN_LIB). I’m currently exploring tradeoffs between 2 and 3. My current thinking is of an alternate “command syntax” for Kitten, suitable for the CLI and interactive mode, with access to a compiler API. Having infrastructure in place for alternative notations would also help #170, and in the future, the implementation of a visual Kitten editor. My initial ideas for how the command syntax would differ from regular Kitten include:
Long flag: --word = word
Long flag with argument: --word=term = term word
Short flag: -w = w
Short flag with argument: -w=term = term w
Bareword string literals: meow.ktn = "meow.ktn"
This isn’t quite right yet, because it would make --word term a common error when --word=term is the intended meaning. But with something like this, you could do standard things like kitten meow.ktn -c -omeow -O2, and also niftier things like loading a source fragment and querying the dictionary:
$ cat >greet.ktn
define greet (List<Char> -> +IO):
-> name;
["Hello, ", name, "!"] concat say
^D
$ kitten --load=meow.ktn --info=greet
word
defined at greet.ktn:1.1-7
with signature '(_::List<_::Char> -> +_::IO)'
with no parent
It’s unfortunate that Kitten’s standard syntax uses a lot of symbols that require escaping or quoting in Bash. I doubt people will want to write a lot of Kitten code within the shell, but we should try to reduce friction as much as possible.
Note: this is not referring to Kitten’s interactive mode (REPL) but rather how a programmer uses the compiler on the command line.
Ideally, I’d like for the compiler to adhere to a few rules:
To reduce assumptions about the environment, it should not implicitly use any Kitten-specific environment variables or configuration files. For example,
LANGandEDITORare fine, butKITTEN_PATHis not.Command-line flags should be Unix-like and reasonably familiar to people who use other compilers, to reduce the chance of mixing up flags.
The interface should be flexible and easily extended, piggybacking as much as possible on the existing language infrastructure.
We’re good on number 1 in the new compiler (the old one only used
KITTEN_LIB). I’m currently exploring tradeoffs between 2 and 3. My current thinking is of an alternate “command syntax” for Kitten, suitable for the CLI and interactive mode, with access to a compiler API. Having infrastructure in place for alternative notations would also help #170, and in the future, the implementation of a visual Kitten editor. My initial ideas for how the command syntax would differ from regular Kitten include:--word=word--word=term=term word-w=w-w=term=term wmeow.ktn="meow.ktn"This isn’t quite right yet, because it would make
--word terma common error when--word=termis the intended meaning. But with something like this, you could do standard things likekitten meow.ktn -c -omeow -O2, and also niftier things like loading a source fragment and querying the dictionary:It’s unfortunate that Kitten’s standard syntax uses a lot of symbols that require escaping or quoting in Bash. I doubt people will want to write a lot of Kitten code within the shell, but we should try to reduce friction as much as possible.