Creating a metaphorical compiled scripted language.

Question

I'm studying for a final exam and I came across this question which I found pretty interesting. I was wondering what the stackExchange community who are more experience in scripted languages than I had to say.

If you were asked to design a scripting language which was compiled, how would you achieve this without losing the benefits of being interpreted.

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. What else could I add?

Answer 1

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.

How would that speed anything up? Practically all of the CPU time is going to into "eval" rather than "read" and "print".

If you were asked to design a scripting language which was compiled, how would you achieve this without losing the benefits of being interpreted.

Well, what are the benefits of an interpreted language? (1) You don't have to compile code to run it and (2) You can easily implement "eval".

To keep (1), you can compile on the fly (like Java does). But it's actually quite hard to keep (2) because you have be able to constantly accept more code that has to link seamlessly with code you've already compiled. What makes this hard is, for example, the case in which an "eval" statement provides a definition of a function later invoked outside "eval"). These problems can be addressed by not having a conventional linker and instead maintaining a global table of functions and, perhaps, keeping the type system simple (e.g., strings and integers).

Answer 2

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

#!/usr/bin/env mycoollanguagecompilerimmediate

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:

#!/usr/bin/env ruby

ENV['SCALA_HOME'] ||= '/opt/scala'

# some code to locate the most recent JDK version
# some code to locate the most recent Scala version
# …

exec("#{scala} #{ARGV[0]}")

# 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.

Answer 3

It is either a trick question or very poorly though out, because there is no exact definition of "scripting language", and hence no clear distinction between scripting and compiled languages.

Or maybe the question is just really old, because traditionally "scripting languages" referred to interpreted languages, while "compiled language" referred to statically typed languages which were compiled into stand-alone binaries. But in the last 25 years there have been so many new approaches to compilation blurring the distinction that these terms are seldom used anymore.

For example JavaScript was conceived as a scripting language (hence the name!) but is often compiled today, while C# was conceived as a compiled language but today supports on-the-fly execution of source code (through the Roslyn framework).

So I guess you could answer "Python" or "C#" to the question.