Re: Inline Functions

["Peter Hill" <corwin@...>]

Peter Hill:
> I'm writing a Lua parser in Visual Basic so I'll try tinkering with the
> syntax in that first, and report back any suggestions / problems.


Björn De Meyer:
> Please, reconsider. Visual basic is the exact opposite of what Lua is
> supposed to be: portable, small, and open software.

Good point.

However it's really more of an indulgent exploration than a suggestion for a
final implementation. I hope writing it will give me a better feel for some
of the problems faced implementing the language, and a better understanding
of the internals. For example, writing the lexical analyser has already
showed me a few lexical ambiguities in the current documentation.

And VB is an environment where I can quickly whip up & debug a simulation.
The lexical analyser only took about 2 hours to write. I expect the parser
to take about 4.


> If you really need a Lua parser in VB, then it will be a lot faster to
> simply compile liblua and liblaux into dlls that export their
> functionality, and then import that functionality into VB.

That is the ultimate goal, I agree. I'd prefer a compiled DLL or OCX .
However I've never tried creating any COM compliant DLL's, so I'm sort of
puting it off. :-O

> I even think this may already have been done some time ago...

It was? Any idea where??? =:-O


> If you rewrite the parser in VB, then that parser, plus your modifications
> to it will be unacessible to those of us who don't use windows, or wo
> refuse to use proprietary programming languages.

Good point.

And a good stance about proprietary languages... I've love an open source
version of VB!

Hey, maybe someone should write an open source Operating System based on
Lua! It would make an excellent core... and I've always supported the
Smalltalk view that a core programming language / compiler should always be
available.

In the original Smalltalk environment the popup menu had the following
options that operated on selected text: Cut, Paste, Copy, Print, and DoIt.
"DoIt" actually immediately compiled to bytecode and executed the piece of
text selected... and could be done anywhere that text could be editted!!!


> Not to mention the bloat, ...

Actually, I hope it will be quite small in VB since all the heap stuff etc
already exists.

> slowdown...

Not really important as I intend it merely as a debugging environment.

> ...and "reinventing the weel" that will happen.

As I said above the "reinventing the wheel" is more to give me a better feel
for the internals of the language, rather than as a real final environment.


> It would be best if you tried to incorporate the changes you proposed into
> the C version of Lua 5.0 beta.

I thought adding changes to the beta version was being discouraged?


> Some of the changes you proposed are relartively for a C programmer to do.
> You do know how to program in C, yes? Then please, implement your changes
> in C, so I can give your ideas a chance.

Yes, I can program in C. If you want to try out the changes then I can do
that. At the moment, however, I've mostly only suggested some minor syntax
enhancements so I'm not sure how much there is to try in that.

*cheers*
Peter Hill.