The question is nonsensical.
Interpretation and compilation are properties of the implementation, not the language. In other words, they are properties of the interpreter or compiler (duh!). Every language can be implemented with a compiler, and every language can be implemented with an interpreter. Talking about a "compiled language" or "interpreted language" is not even wrong, it is nonsensical. If English were a typed language, "interpreted language" would be a type error.
Also, packaging up the program together with the interpreter into a single executable is indistinguishable from compilation, and compiling and then immediately executing is indistinguishable from interpretation.
E.g. the Scala "interpreter" is actually just the compiler which executes the code immediately. Likewise, the tcc (tiny C compiler) has a scripting mode, which simply compiles the file and executes it.
One point I thought of was to create a compiled version of a Read-eval-print to test mini functions faster than compiling a whole program for ease of testing.
This has nothing to do with the design of the language. This is an implementation problem. Your question was about designing a language, not implementing one. Those are very different things. For one, designing a language is done in English, implementing a language is done in a programming language.
What else could I add?
Well, what does "scripting" mean? It basically means dynamically interacting with objects you don't control. That's the gist of scripting: you interact with "something else". That "something else" provides the data types, the objects, and even most of the operations. A shell scripting language interacts with the operating system; the operating system supplies the objects (files, processes, sockets, threads, devices, …) and operations (reading, writing, copying, …). A web scripting language interacts with the document and the browser; the browser supplies the objects (DOM nodes, …) and the operations (DOM API, …). AutoLisp interacts with AutoCAD, Photoshop has a scripting language (I think?), etc., those languages interact with 3D models or photos, and the operations are supplied by the "host".
So, a script interacts with objects whose types it doesn't control and whose lifetimes are independent of the script through operations that are supplied by the host. That's what "scripting" means.
What does "scripting language" mean? Well, nobody knows, exactly. Is it a language with which you can do scripting? You can do that with any language, that's not a useful definition. (Just like you can do functional programming or object-oriented programming with any language.) I, personally, would define it as a language that facilitates scripting and makes it easy.
According to what we wrote above, a scripting language needs flexibility. A dynamic type system or an expressive static type system allow the language to deal gracefully with the fact that most types and objects originate from the outside. Some form of automatic resource management is highly desirable, since the language mostly interacts with objects whose lifetimes it doesn't control, and trying to do this with manual resource management can get messy. (Whether you choose monadic regions, garbage collection or something else entirely is up to you.)
And one small thing: in order to be useful in Unix as a scripting language, it needs to be able to deal with the fact that that first line of the script will be something like
See Scala for an example: in Scala, that would be a syntax error (unlike many scripting languages, Scala does not use
# for comments). However, in scripting mode, Scala ignores everything up to and including a line consisting of
!#, which allows you to write something like this:
ENV['SCALA_HOME'] ||= '/opt/scala'
# some code to locate the most recent JDK version
# some code to locate the most recent Scala version
# Ruby code ends here
// Scala code starts here
That's all I can think of: a powerful flexible type system (see PowerShell or Mondrian for examples) and support for shebang lines. Both of which has nothing to do with compilation.