Lemon – An embeddable, lightweight programming language in ANSI C(github.com)
github.com
Lemon – An embeddable, lightweight programming language in ANSI C
https://github.com/lemon-lang/lemon
21 comments
> So I guess this is all at a very early stage of development.
That should be the top link
That should be the top link
Submitters here have developed a truly odd habit of posting a github link when a project has a site with actual documentation. And then, we get random, angry posters (visible elsewhere on this page) who don't notice the link to the actual site at the top of the github page.
[deleted]
Or who think "if the github is in this state, the site's probably terrible!"
How about this link instead, since the GitHub page has no info about the language?
http://www.lemon-lang.org
http://www.lemon-lang.org
I agree. Maybe http://www.lemon-lang.org/documentation ?
Not to be confused with SQLite's Lemon parser generator:
https://www.sqlite.org/src/doc/trunk/doc/lemon.html
https://www.sqlite.org/src/doc/trunk/doc/lemon.html
Why is the `var` keyword required in function arguments if it's dynamically typed and there's no other possible option?
So you don't create variables when you typo a variable name. Declarations are an error catching mechanism
This is a complete guess, but maybe so they can treat it the same way as normal variable declarations
Might be. Probably reusing the same pattern matching code in function definitions.
Nice seed for random number generation used here: https://github.com/lemon-lang/lemon/blob/9a0b3dbc854532b31f7... I'm not sure because I haven't read very far yet but I wonder if the lemon standard lib allows lemon code to change the seed?
Went to the doc directory and got this:
TODO: Add Doc
Could developers please stop doing that? These 'agile development' and 'release early and often' mantras have really gone overboard.
Why would anybody use a programming language with zero documentation for anything? Are we supposed to guess the language and its features from a single five-line hello world program?
TODO: Add Doc
Could developers please stop doing that? These 'agile development' and 'release early and often' mantras have really gone overboard.
Why would anybody use a programming language with zero documentation for anything? Are we supposed to guess the language and its features from a single five-line hello world program?
In all fairness: there seems to be a little bit more of documentation on http://www.lemon-lang.org
So, whoever posted this to hacker news should have used that link rather than the GitHub link and of course, it seems to be way to early in development to post it at all. I have some quite unfinished projects of mine on GitHub, but I would never post a link to them until they are in a state where they would be relevant to a larger community.
[deleted]
> Why would anybody use a programming language with zero documentation for anything? Are we supposed to guess the language and its features from a single five-line hello world program?
As someone who has done a handful of compiler/interpreter projects: I don't think that they expect anyone at this point to be using that language. They're targetting it at language geeks like myself (who go and dig around the source, which I just did). Maybe in some years' time this project will reach a stage where end user docs matter.
A little more verbose readme would have been nice, though. Things that I did not find out by looking at the examples/docs, but I care about:
As someone who has done a handful of compiler/interpreter projects: I don't think that they expect anyone at this point to be using that language. They're targetting it at language geeks like myself (who go and dig around the source, which I just did). Maybe in some years' time this project will reach a stage where end user docs matter.
A little more verbose readme would have been nice, though. Things that I did not find out by looking at the examples/docs, but I care about:
* what paradigm? imperative, functional, etc?
* interpreted or compiled language?
* what's the target? interpreter, a bytecode VM, LLVM, compile-to-C, native codegen?
* static/dynamic typing? type inference?
I'm a language geek and none of the above is what I want to see when I read about a new language. What I want to know is, what does this language offer that no other language does? What platform it runs on or whatnot is trivial boring detail that I might want to know afterwards if the language offers something interesting to try out.
>What platform it runs on or whatnot is trivial boring detail
Not caring about actual usage mechanics / acting like they are trivial details makes me question a lot about your perspective.
Not caring about actual usage mechanics / acting like they are trivial details makes me question a lot about your perspective.
Language X runs on platform A, it offers little innovative but merely re-expresses what you're already used to doing on platform A in another language.
Language Y has some really innovative features that no other languages are currently doing. There is currently no reference implementation.
Which of these is the more interesting one to a language geek? The former might be more interesting to a "platform A" geek. Or someone who uses platform A in production.
The perspective is being interested in language design rather than "the next big thing". A language that doesn't change the way you think about programming is not worth learning, because you're only re-learning what you already know. In fact, learning such language is trivial and all you really need is a grammar reference from which you can deduce the rest. If it runs on platform A which you're familiar with, you can take advantage of platform A's libraries and become productive in X in no time.
Language Y has some really innovative features that no other languages are currently doing. There is currently no reference implementation.
Which of these is the more interesting one to a language geek? The former might be more interesting to a "platform A" geek. Or someone who uses platform A in production.
The perspective is being interested in language design rather than "the next big thing". A language that doesn't change the way you think about programming is not worth learning, because you're only re-learning what you already know. In fact, learning such language is trivial and all you really need is a grammar reference from which you can deduce the rest. If it runs on platform A which you're familiar with, you can take advantage of platform A's libraries and become productive in X in no time.
Lua.org's Lua is a VM, but a register based one. Perl 6 is another odd case of register based VM
It is dynamic, curly braced, garbage collected, coroutines. Some really squeaky clean C code too. One can immediately tell this is a great code base to read and learn from, at the very least.
What's so squeaky clean about hiding a goto inside a macro?
I guess you're referring to this[1]. I'd actually call that usage svelte. The macro is undefined not far after it's use in the file, and makes the section it's in far more readable.
[1] https://github.com/lemon-lang/lemon/blob/9a0b3dbc854532b31f7...
[1] https://github.com/lemon-lang/lemon/blob/9a0b3dbc854532b31f7...
Why does it have the do-while(0)?
It's a safeguard because {} statement blocks are optional [1].
[1] https://stackoverflow.com/a/923833/2561675
[1] https://stackoverflow.com/a/923833/2561675
> Why would anybody use a programming language with zero documentation for anything?
Why would you write documentation if your language implementation is still rapidly evolving?
Why would you write documentation if your language implementation is still rapidly evolving?
Regardless, shouldn't you at least write documentation to isolate and identify confusing points of your rapidly evolving language? It's almost a matter of good practices; explaining something is usually the best way to learn it.
It depends. The language's author probably didn't post this, so who knows what stage of development his project is at.
You should write the documentation first. Otherwise what are you writing?
You're writing code for a purpose, obviously. Sometimes that purpose isn't clear from the outset, hence exploratory programming. So what would you be documenting at this point exactly?
[deleted]
Developer: Read the source code!
I've seriously seen this kind of response from developers while looking for help using melt (Media Lovin' Toolkit). You typically see this kind of response for better documentation: "melt is for developers. Use one of the GUI front ends to generate a script for you or read the source code."
I've seriously seen this kind of response from developers while looking for help using melt (Media Lovin' Toolkit). You typically see this kind of response for better documentation: "melt is for developers. Use one of the GUI front ends to generate a script for you or read the source code."
Wow you're entitled. The author owes you nothing!
It's not like they submitted this to HN themselves.
It's not like they submitted this to HN themselves.
> Why would anybody use a programming language with zero documentation for anything?
What alternative do you suggest? Not putting it out there until it's production ready?
What alternative do you suggest? Not putting it out there until it's production ready?
seems a bit similar to lua? So little information it's hard to know what interesting things the language provides
Not too much documentation nor examples there, right?
However, the two test files and the documentation website immediately made me think about Python and Nim at the first glance. I might give it a try as an embeddable language, it looks promising.
Interesting optimizations:
https://github.com/lemon-lang/lemon/blob/master/src/peephole...
https://github.com/lemon-lang/lemon/blob/master/src/peephole...
> TODO: Add Doc
It's not a programming language if there's no documentation. It's just a compiler implementation for a dialect of something amorphous and ethereal.
That said, I kind of like the examples on http://www.lemon-lang.org/documentation and I wish the author(s) well in fleshing this out.
It's not a programming language if there's no documentation. It's just a compiler implementation for a dialect of something amorphous and ethereal.
That said, I kind of like the examples on http://www.lemon-lang.org/documentation and I wish the author(s) well in fleshing this out.
What problem does it solve?
Looks like an attempt of a JS programmer to reinvent a lighter weight JS with aim at system programming.
If it is yet again tied to a complex, feature rich VM (a stack based one), then he went the wrong way in achieving his goal. Direct interpretation should've been the way forward for such task.
If it is yet again tied to a complex, feature rich VM (a stack based one), then he went the wrong way in achieving his goal. Direct interpretation should've been the way forward for such task.
A stack based VM or direct interpretation have no real difference with regard to what you mention. Please elaborate further.
You are making very unnecessary comments..
My guess is a lighter weight (than Lua, Python, JS) embed-able language. A quick build creates a .so that is bigger than lua as reported below, but that is a naive and probably invalid comparison metric.
Ref: http://lua-users.org/wiki/LuaVersusPython
make DEBUG=0 STATIC=0 USE_MALLOC=0 MODULE_OS=1 MODULE_SOCKET=1
ls -lh liblemon.so
-rwxrwxr-x 1 guest guest 271K Oct 25 08:21 liblemon.so
Ref: http://lua-users.org/wiki/LuaVersusPython
Except liblemon is larger than liblua.
There are other things that make it less suited for embedding than Lua. For example, Lua very carefully avoids touching any global process state. But one the very first things lemon_create() does it call srandom().
Those particular things, at least, could be easily remedied. Another reason why Lua is great for embedding is because of it's very carefully designed C API. With just a cursory look I can't tell how well Lemon compares on that score.
$ ls -lh /usr/lib/x86_64-linux-gnu/liblua5.3.so.0.0.0
-rw-r--r-- 1 root root 219K Apr 13 2016 /usr/lib/x86_64-linux-gnu/liblua5.3.so.0.0.0
There are other things that make it less suited for embedding than Lua. For example, Lua very carefully avoids touching any global process state. But one the very first things lemon_create() does it call srandom().
Those particular things, at least, could be easily remedied. Another reason why Lua is great for embedding is because of it's very carefully designed C API. With just a cursory look I can't tell how well Lemon compares on that score.
2, What problems are you trying to solve?
A: 1, easily integrate with C. 2, stable and modern syntax. that's all I wanted.
https://github.com/lemon-lang/lemon/issues/6
What's the motivation for this language? It seems like Javascript with destructuring assignment, named function parameters, and a few miner quirks (like sentinal)
It seems like it's meant to be easy to embed in another language's code. Like embedding LUA into a C game engine to provide a convenient way to build higher-level game logic on top of the engine.
JS has destructuring assignment and named function parameters can be emulated, sorta, with parameter destructuring.
Interesting mixture of C/C++, Python (__init__) and Javaish. Has no package manager (atleast I can’t see one).
Would like to see how it compares against Lua in performance.
Would like to see how it compares against Lua in performance.
I'm seeing in the source that the author prefers
type
methodName(args...)
Is this a common C-ism? I'm not familiar with this code style.
type
methodName(args...)
Is this a common C-ism? I'm not familiar with this code style.
It is. It allows to search for function declarations with the regex '^[^( ]+[(]' (or similar) -- while more common in the past, many have adopted it and keep using it.
Personally I've come to find it nice to read, particularly when you're returning complex, long types.
Personally I've come to find it nice to read, particularly when you're returning complex, long types.
[deleted]
The source code is very pleasant to read - both in terms of layout and variable names.
Looks like the documentation website is down right now.
i'd like to see an embedded language designed to not have OO, and for the host system/language to handle the objects. I guess Lua 5.2 kinda fulfills that.
What a lemon
Looks like a mashup of Ruby, JavaScript and tiny bit of Python.
I’m mostly seeing a lot of Python. The examples show that multiple assignment unpacks collections, functions can be called with argument name assignment, and collections can be unpacked into named arguments, as opposed to using collections to replace named arguments.
Ruby supports that too. Here's a snippet that shows named arguments, and unpacking a Hash into named arguments.
It can do multiple assignment and unpacking collections into them too, though unlike with named arguments, that will treat the collection as an Array:
It can do multiple assignment and unpacking collections into them too, though unlike with named arguments, that will treat the collection as an Array:
def foo bar:, baz:
p [bar, baz]
end
h = {bar: 1, baz: 2}
foo(h)[deleted]
"Lemon – An embeddable, lightweight programming language in ANSI C that lacks documentation."
Uh, thanks for posting this strange link, I guess.
Uh, thanks for posting this strange link, I guess.
I see more similarity with Python than either Java or C, except for the braces and semicolons.
The description says that everything is an object, even types, though there's no way to specify types in the function prototypes so far, it seems. (Whilst that is what you would expect from a dynamically typed language, it can still be useful for optional type checking, or for later optimisation (AOT or Jit), or to make it easier to efficiently add methods for existing "types".)
Actually, what I can't quite see from the documentation is how one calls methods, whether it is necessary to put methods inside the classes, whether they dispatch only on the first argument or an implicit "this", and how inheritance is handled.
So I guess this is all at a very early stage of development.
[1] http://www.lemon-lang.org/documentation