Influences About Language Designs
Veeyu is influenced by following languages:
Homoiconicity from Lisp And Io
Lisp handles codes as data, exactly, cons lists. All abstract syntax tree is just nested lists containing symbols. So, Lisp codes are inspectable and modifiable in runtime. This feature makes Lisp good at metaprogramming domain-specific language. Io has the fundamentally same feature, but is designed object-oriented, and codes are objects that are named Message also instead of lists.
The author thought Lisp’s idea is powerful and elegant, and Io’s reengineering with object-oriented design makes the idea more comfortable and modern. Veeyu borrows it directly from Io.
However, Io has a small problem that higher-order functions in its core API takes not lambdas e.g. list(1, 2, 3) map(method(x, "#" .. x)) but messages literally e.g. list(1, 2, 3) map(x, "#" .. x). Writing methods that take message literally and evaluate it is not easy in Io, so, it’s annoying for API developers. Of course, taking blocks as lambda is able in Io, but it seems awkward, because such style cannot be found in most Io codes including standard libraries. The problem is only about style, anyway, Veeyu isn’t derived even such style from Io.
Common Lisp Object System
Veeyu borrows the metaobject protocol from Dylan that adds integrated object systems derived from CLOS. Class as object, multiple inheritance and C3 superclass linearization…
Most identifier naming conventions also came from Dylan.
Lisp1
Like Scheme, Python and JavaScript, Veeyu does not follow Lisp2, but Lisp1: there is only one namespace. Common Lisp or Ruby separates namespace for functions(methods)—Lisp2 model is that. It is usually referred to as the Lisp1 vs Lisp2 debate.
Universal one namespaces make evaluation model simpler and natural to treat functions as value.
Evaluating methods in JavaScript is aware of the receiver: special variable this is decided by the receiver of its calling form. I think such behavior of JavaScript makes object model complex and disadvantages to reuse functions as value. Because method objects doesn’t bind this until be called: it should make a new lambda in order to bind the receiver as this to method objects e.g. higherOrderFunction(function(a, b) { return receiver.method(a, b); }) instead of higherOrderFunction(receiver.method). In Veeyu, methods of the specific instance bind its receiver.