Lambda the Ultimate

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.

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

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.

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

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

i was trying to make hashtables more pervasive

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

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.

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.

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