Mila

Mila takes a minimalistic approach to language design: As much as possible is delegated to libraries, the rest is a small set of language constructs. Hashtables, lists, objects and namespaces are all the same thing, for example. Other features: All parameters are named and have default values, variables are strongly typed, and there's a nice syntax to write objects with indentation.

I am the author of the language and all feedback is very welcome.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Does not look small

I would not like to sound harsh, but this does not look like minimalistic. After reading the first statement I thought about Scheme. After reading the whole post I thought - how to implement all these features in a minimalistic design.

I think the documentation would benefit from splitting into several sections, like overall paradigm, trade-off policy (like prefer succinctness to usability, or readability to compiler performance), approach to control, approach to data structures, is it a DSL or a general purpose language, how it relates to other PLs.
At least a sketch of operational semantics would be great, though I am not insisting on it. Only then is the audience ready to consume specific types, syntax, and examples.

AutoKey puzzles me, probably because of monolithic documentation... Was it really necessary in a minimalistic language?..

Hope this feedback was welcome. I am positive more will come if you elaborate on the topics I listed. It's what the discussion threads are for.

Great suggestions

Thanks for your feedback, it is invaluable.

I'll try to address your points one after another. It's true that Mila isn't as small as Scheme, but one might argue that "minimal" isn't the same as "small". I'm glad you mentioned this, because I hadn't thought about the difference much. I would define a minimalistic design as the smallest design that implements a given set of features, which is quite different from just "small". Hmm, does that make sense? Of course it is still important to pick the right features.

What you say about the documentation is really useful, because I've been having a hard time putting myself into the position of the reader of the documentation. I will try to incorporate your suggestions as soon as possible.

I'm not really sure I understand "operational semantics". Do you mean how a Mila program is executed? A Mila program is simply an Object and is created/executed like one.

The AutoKey type is necessary so Objects can behave like lists, for example. Also sometimes you simply don't care about giving a specific key to a value. Leaving away the left side of a statement implies an AutoKey, by the way.

Once again thanks for putting up with the bad documentation and your great suggestions. I hope I'll get the documentation improved fast. Getting this kind of feedback on the actual language features would be very cool. Also I think other than the documentation, the language itself is quite nice, actually.

Tutorials

I've added two tutorials to Mila's documentation and Mila's interactive mode has been improved. Getting an idea of how Mila works should hopefully be easier now.

a hashtable language

i wondered about this some time ago - whether you could make a language that uses only hashtables. i ended up with a mess because sometimes i wanted sequential lists and sometimes i wanted hashtables, and the ordering in the two wasn't the same. does your autokey resolve this?

iirc i had a problem with parameter lists - using hash tables sounds like a great way to have named parameters. but what if you want parameters to be implicitly named by position?

what do you use for implementation? i think i was considering skip lists for some reason (can't remember why now - maybe a trade-off so that joining tables was efficient?) (do i have the right name? the data structure with random length links "forwards", rather like a randomized tree on its side)

(i hope you already know that languages, rather like children, look much prettier to their parents - i think i can understand why you have done this, because i wondered about it too, but i can't say that it looks very useful or very beautiful :o)

a question about syntax - why do you have a = 'b' rather than 'a' = 'b'?

and do you have inheritance in your objects?

i guess this is of no interes

i guess this is of no interest, but the only notes i scribbled down while thinking about this are here and the day before.

so - do you have curried functions?

i guess this is of no interes

i guess this is of no interest, but the only notes i scribbled down while thinking about this are here and the day before.

Great to see such similar ideas :-).

so - do you have curried functions?

No. I haven't ever used currying or a language that supports it, so I don't know much about the advantages. You could still add it to the language by writing a function that curries other functions, of course.

AWK

AWK primary compound data type is the associative array, which from an implementation point of view can be implemented using the data structure "hash table."

However, I don't think that's the parameter passing mechanism.

Perl/Python and similar languages use hash tables and dictionaries frequently as well, but I don't recall something related to what you are thinking about.

you might check out Lua

In Lua, the basic data structure is the table. Sequences are simulated using tables with numeric keys (i.e., arrays), and a set of library functions that are smart about interpreting tables as arrays/lists. But there's no hard/fast distinction. Paramater lists can be packed/unpacked to tables as well in a reasonably elegant way.

There are a few warts, imho, but all in all it's a pretty good system...

Interesting

i wondered about this some time ago - whether you could make a language that uses only hashtables. i ended up with a mess because sometimes i wanted sequential lists and sometimes i wanted hashtables, and the ordering in the two wasn't the same. does your autokey resolve this?

I had this problem, too, and I decided to simply combine list and hashtable into what I call an "object", so I can have the best of both worlds. Autokey alone can't solve all the problems, I think.

iirc i had a problem with parameter lists - using hash tables sounds like a great way to have named parameters. but what if you want parameters to be implicitly named by position?

When a function is called I copy the parameters that have names/keys first. The rest is then filled up with the parameters that only have autokeys.

what do you use for implementation? i think i was considering skip lists for some reason (can't remember why now - maybe a trade-off so that joining tables was efficient?) (do i have the right name? the data structure with random length links "forwards", rather like a randomized tree on its side)

I'm using normal hashtables and lists.

(i hope you already know that languages, rather like children, look much prettier to their parents i think i can understand why you have done this, because i wondered about it too

I'll take the fact that you independently thought of the same thing as bullet-proof evidence that it's a good idea ;-).

, but i can't say that it looks very useful or very beautiful :o)

You can use it to program computers. I think that is at least somewhat useful :o). Regarding "beautiful", I'm sure one gets used to the indentation etc.

a question about syntax - why do you have a = 'b' rather than 'a' = 'b'?

a is short for ['a'] which means " the value stored under the key 'a' ". I thought it would be more logical to assign values to values, instead of values to keys, so to speak. And a='b' is shorter to write and looks more like the assignment of variables in other languages.

and do you have inheritance in your objects?

I hope that won't be necessary but I'll have to think some more about it.

as others have said, you may

as others have said, you may find lua interesting - it has a solution for inheritance, for example (calling something objects without inheritance might upset a few people ;o). looking at my notes i think i was trying to make hashtables more pervasive than lua (ie more like your approach).

Specification not implementation

i was trying to make hashtables more pervasive

They are maps, Andrew, maps, not hashtables :o)

I already had a look at Lua.

I already had a look at Lua.

Inheritance only makes sense if you have classes. In Mila you copy the object you want to inherit from and extend it.

Some similar ideas

You can have a look at the basis of another language based on maps in the MPOOl 2001 proceedings, page 97, available online here.

The language is called Gens. The main difference with Mila is that it's based on a formal calculus of maps, or hashtables as you call them. I tend to call them environments. The term "hashtable" is misleading because it's only describing one possible implementation of maps, and not the most efficient one at that.

Anyway, the fundamental ideas seem to be similar. In Gens, environments are used to represent all values except primitive integers and strings. There's a total of seven language constructs that, combined with labels (i.e. keys) and environments, can emulate pretty much any programming style.

Since my goal was to design a really minimal declarative language usable for multiparadigm programming, I started by designing a calculus. From what I could deduce, your starting point was the object-oriented programming paradigm. Lua has already been mentioned. You should also examine the Self language and other object-based languages, if you haven't already.

Looks very interesting.

Looks very interesting. I especially liked the idea of values being always tied to their environment.

I wondered about adding operators for maps, too, but I ultimately decided to use functions as the second abstraction.

Thanks

Yes, you could say that the main difference lies in functions: Mila has the function (in, out, do) construct with special semantics while Gens provides simpler constructs that let you build functions.

One thing that's not quite clear to me from the examples and the language definition is whether Mila functions' do attributes can have access to global environment and global side-effects on it or not. If not, then the only purpose of the out attribute is to distinguish the keys that are meant to be returned from the keys that are a discardable byproduct of the calculation. Is that correct?

The Gens approach is to simulate the out attribute by using the selection construct. Instead of having a built-in function call semantics that performs a calculation of do attribute and then selects its desired part according to the out attribute, Gens just evaluates the function value which may or may not have the selection form do.out.

The do attributes can have ac

The do attributes can have access to environments other than its own. Mila is dynamically scoped to enable objects (as in object-orientation) to carry around their methods. Keys not found in the local environment of a function are searched either in the function and its parents or in the function's caller and its parents and callers. These keys can also be assigned to from within the function body.

Whether the parent or the caller is searched depends on the value of search, which can be set in in, and which can have the values 'parent' or 'caller', with the obvious meanings. If search doesn't exist (as in most functions) its value is assumed to be 'parent'.

What you say about the out object is correct, although additionally out gives the return values default values (and thus types).