Review of a potential pramming language: Lima

Over the last 4 years I've compiled ideas about a programming language and have written a more or less extensive specification of the syntax. I was hoping some people here could review it for me. Link:

I welcome any criticism, potential issues, or any other kind of discussion in general.

On a separate note, if anyone wants to help me develop the language, I would love the help.

Comment viewing options

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

Three things

  1. Read Frank Atanassow's Some words of advice on language design (which should probably be in the LtU FAQ), since at least thinking about these potential objections before posting here increases the chance of getting useful feedback;

  2. Take a look at Learning to program with Alice (relevant to multiprogramming), and The Role of the Study of Programming Languages (relevant to your ideas on transparent programming).
  3. Write up the case for your language to be developed, anticipating Frank-like objections.

Your goal of "transparent programming" is interesting, but undeveloped. You should make clear how you hope that this will work. A programming language in general needs not just syntax, but also semantics: formal or informal, you can't just let the reader guess what is intended.

To be blunt, I don't think there is any chance that anyone skilled at implementation will be enthusiastic about your language design as it stands.

Show what's different

If you want feedback, demonstrate the ways in which your language is different and interesting. Detailed syntactic specifications aren't useful; languages are so similar at the syntactic level that most of it is boring boilerplate.

I think the best way to "sell" is to describe a bunch of problem instances where your language does better than other languages. Your front page does this at a high-level by describing a few problems your language tries to fix. You need to have more of these with concrete examples. A very good example of this is Scala's "A Tour of Scala" page.

Thanks for your comments. I

Thanks for your comments. I read Frank's advice, and some of the Role of the Study of Programming Languages. I couldn't read the Alice book because I'm not about to buy it.

Kannan: I updated the link to the main page for Lima (which Charles apparently read). It is much more like "A Tour of Scala" than the syntax page.

The "transparent programming" idea is something I see in my head as expandable and hidable tabs. What i mean is that if you have:

[ wout = "hello "
wout = "!"

you could press a button (i'm imainging one with a little "+" on it) that would "expand" some lower level code out so you could see how the compiler is translating it. You could expand into something like C:

for(int n=5; n>0; n--) // done backward cause of html...
{ printf("hello ");

or you could expand it into assembly (I won't write that down..). The reasoning would not only be to learn whats underneith, but also that a programmer could optimize the code in some special way without hindering readability. Potentially even a function call could be opened up and messed with. Perhaps you want to use a function's general actions, but want to tweak them slightly. Obviously it would no longer be a true function call, but the abstraction can be saved.

One of my answers to Frank's question 1 is indeed "its cleaner", however thats not my only answer. Frank made another comment about how "it doesn't matter" what syntax you have. Why would I design a programming language if I was not concerned with syntax? I could just write a library as he suggested. The goal of my syntax and semantics is that it makes learning the language AND actual programming significantly faster.

The language's purpose is to make translating an idea into a program as quick and easy as possible. Syntax is terse, and the language is focused on program description rather than program optimization. My feeling is that optimization is the compilers job, and if they can't do it well now, we'll program them to do it better tomorrow.

I take issue with Frank's question 3 - almost all languages I have looked at can be used to solve almost any problem. General programming languages are made for anything. However, what is important is *how fast* a programming language can solve a problem. Speed is key. One thing I think Lima can do faster than any other programming language is parse. I wrote a description of a "parse function" (which isn't up to date on the site) that can be used to parse any input. One can even use this parsing to write a "Custom function" which in essence can allow a person to write anything from an elegant function syntax, to an entire separate language. The goal is to allow the user to define their own syntax if they think its a good idea.

In essence, this is the language I would use if I could magically produce one. A language that does all the nasty things for me automatically, and just lets me get ideas out. It would allow me to write a few lines down and have it produce an EFFICIENT and optimized binary that executes a 3d scene with sounds and action - without having to do a bunch of syntactic busy work. I can't explain my whole vision right here and now - I'll just have to make my website describe it better.

But wouldn't that

But wouldn't that transparent programming be incompatible to a lot of more advanced compiler optimizations? I mean it depends on a pretty strict one to one correspondence between source and object code.

I think the obvious idea

I think the obvious idea there is to treat compilation in a manner akin to tactics in theorem provers? So you actually pick which passes the code goes through, though you may well often just use the equivalent of 'auto'.

On incompatible...

"But wouldn't that transparent programming be incompatible to a lot of more advanced compiler optimizations?"

I don't think so. One could choose the optimizations you want to see, and if its whole-program optimization... well you're going to see what parts of your selected area are left after those optimizations. If for some reason, its simply too complicated to show you, perhaps it will give you a note saying as much. Alternatively, you could restrict the expansion of lower-level code to easy cases - but why restrict the programmer?

Like Philippa said, the idea is to simply allow programmers to futz with their code at whatever level they want in a way that makes everything easily readable. Part of the goal of the language, however, is to make any manual futzing completely unneccessary (because of freely available or open-source compiler optimizations).