[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: C with embedded Lua or Lua-only program?
- From: Silas Silva <silasdb@...>
- Date: Fri, 3 Sep 2010 13:02:01 -0300
On Fri, Sep 03, 2010 at 07:00:20AM +0200, Philippe Lhoste wrote:
> On 03/09/2010 03:55, Silas Silva wrote:
> >1. Is there any replacement for lex/flex& yacc/bison for Lua? How do
> > you design DSLs in Lua? I thought about using Lex& Yacc + C it is a
> > long standing wish of mine to learn parsers, BNF with Lex& Yacc...
> As said, Lpeg is well fit for the task. Not BNF, so it pushes you away
> from your wish, but still fun to use and powerful. Actually, it uses a
> kind of DSL itself to express the parser.
Great. Going to take a look.
> >2. I was thinking that it would be interesting to make the DSL
> > Turing-complete, to make it easily programmable. Use Lua itself as
> > the DSL would solve this problem, but what about if I need different
> > syntax not present in Lua, like in "button foo ..."?
> You will be surprised to see the power and flexibility of Lua... People
> made surprising things with the Lua syntax pushed to surprising results,
> thanks to existing syntax sugar and metaprogramming.
> Now, you need to have a good understanding of Lua to express what you
> want this way, and indeed you will need to express your DSL within the
> limitations of this syntax, ie. you won't be able to do anything you want.
> On the other hand, you will get speed, some debug capability, etc. (IDE
> support if Lua was well supported...).
Yeah, I have already seem some examples, and without using the must
interesting features of the language...
BTW, you told me about debugging Lua... There are some IDEs out there
that can debug Lua code, but is there any standalone application (like
gdb for C/C++) that does that? What about debugging techniques? I'm
already looking for it in my favorite search engine, thanks :-)
> >3. Is there any reason about why to develop it in C + Lua instead of Lua
> > only?
> In some cases, speed (this have been discussed recently, the advantage
> is smaller with LuaJIT).
> And obviously, to provide low level, system access (you won't display
> graphics with pure Lua!).
> Traditional approach is to provide a core, small C application (too
> bootstrap), offering a number of services via libraries, and to write
> most of the logic in Lua. Going back to C if it is proved to be slow in
> some domains.
That is a very good example, thanks. As told, the Lua interpreter is a
C program that embeds Lua itself...
> >4. Am I reinventing the wheel? If yes, could you point me to open
> > source solutions on this problem?
> There are a number of GUI libraries for Lua, as mentioned, from wrappers
> to popular C GUI libraries to thin layers over the native components
> (IUP) or rewrite from scratch (drawing the components over a graphics
> frame) like tekUI.
> I suggest to search the archives as most of them have been announced here.
> Note: since they are open source, you can rewrite them (or add a layer)
> to use your own DSL for describing the GUI.
I have never used IUP and tekUI. They doesn't seem to solve my problem,
but seem to be toolkits that can be supported by the program I'm
planning to write... I'm going to try them, anyway. Thanks.