The answer: don't. There are enough already. Use Lua, or Java Script, or a similar language. Only write a language if you're positive you need one - and if you are, you're a language expert, and wouldn't be asking this question.

A bit blunt... It is true that there are plent of languages out there, and that writing a language is hard work but there can be an element of fun in it. I know that is one of the reasons I'm doing it.

Also the question wasn't about whether to write a scripting language or not, it was about how to do it. But you have a valid point none the less.

Quote:

Original post by Pxtl Only write a language if you're positive you need one - and if you are, you're a language expert, and wouldn't be asking this question.

Well, what if he wants to do it for fun or for the benefit of learning experience associated with rolling out your own scripting language?

Well, that's fine. Just try and avoid making some sad attempt to amass a university underground developer community and pluging it into some niche product market so I have another freaking obscure language to learn (today's wierd language: Inno Setup Pascal Script - its so _almost_ Pascal, but not quite!).

Quote:

Original post by CoffeeMug I thought Boost::Spirit is a very interesting proof of concept (the concept being advanced hackery of C++ language)

If you think boost::spirit is c++ hackery, you haven't tried boost::phoenix, just the description: "In as much as Spirit attempts to mimick EBNF in C++, Phoenix attempts to mimick C++ in C++"!!!

Quote:

Original post by CoffeeMug but is absolutely unusable in real life. Compilation times being one of the major problems (although it should improve with the newer compilers). I also thought the architecture was an ugly piece of crap. I didn't understand much about templates back then, so I might want to go back to Spirit and reevaluate it again. In any case, to each his own [smile]

Yeah, compilation time sucks, so wrap the parser in a few classes, make sure boost::spirit is only included into those classes .cpp file, and you should never have recompile them after they are first complete.

Though I would be suspicious if a scripting language needed to be very fast (all the hard stuff is in something closer to the metal, right?), generating MSIL to run on .NET is relatively easy.

This could be particularly beneficial if your game engine is already .NET centric: the scripting language could communicate with your engine components without requiring any glue-code.

hello guys,

Have anyone tried using Visual Parse++ from Sandstone to write a parser, well rather a script Processor.

I am in the middle of one.

It nicely wraps the lex and yacc and lets you work seamlessless, but, but, but...

And right now at a stage to figure out, how i can execute the defined rules.

While i am tring to figure out the different approaches like Building an execution tree etc, I bumped across this interesting group.

Would like to hear from you guys, if anyone had any experience with Visual Parse.

Well, i am not into any game development, but I am into some real time data acquisition and processing application.

Any inputs would help.

Regards,
Venkat.

Quote:

Original post by Kylotan Quote: Original post by Sneftel Keep one thing in mind: Implementing a non-trivial scripting language directly in C++ will be much harder than learning and using tools for lexing and parsing such as lex and yacc. To be honest I found it easier to write a simple recursive descent parser than to work out how lex and yacc work, and that was with a background in Backus-Naur form and various grammars. Those tools are awkward and poorly-documented in my opinion. But maybe others find it to be the other way around.

Ditto to BOTH these quotes. When I was still at university, and deep in compiler-theory, I was able to crank out complex parsers extremely fast (so fast it was once faster for me to make a custom parser than to learn all the oddities of perl5 regexps, for instance - although I blush to remember I even tried :( ).

But then a few years later I began to notice that parsed languages I was working on kept hitting roadblocks where the syntax required a different parser. One I particularly remember as irritating the pants off me was non-trivial nested loops (e.g. parameterized nested loops) - I knew they were damn simple to handle in theory, but found the parser I'd implemented happened to make them extremely tortuous to implement :(.

I've tried the various yacc, lex, etc, and generally found the documentation and usage absolutely evilly difficult. My recommendation? If you are going to get the dragon book anyway, then learn yacc, lex, etc - with the book in hand, you can guess how they work rather rely on their poor excuse for docs.

Interesting that no-one's mentioned this (perhaps says a lot about your backgrounds ;)), but ... howabout java?

(ducks and runs for cover)

A lot of C++ people who have friends or colleagues working in high-performance situations with java recommend java the language as a scripting lang, becuase they're often being told how fast it is nowadays, and how safe.

That's a huge rococco example of failing to get the point...java is a systems language, and pretty poor for scripting (like C++ it's too much hard work for the programmer to be a good scripting language).

But...it has the world's fastest VM, since almost all the optimization by Sun and IBM in the last 10 years has gone into that VM. So, if you compile your language to java bytecode, you'll get the FREE java VM to run it on.

This has proved a tempting lure for many projects - hence versions of Python, Ruby, SmallTalk, Eiffel, all compiling to java bytecode to run on a javaVM. But it's not that easy; java bytecode is quite powerful and quite quirky :(. Much simpler than writing your own C-to-assembler compiler, but with plenty of difficulties to handle.

IF you make your bytecode compiler properly you will get a damn fast scripting language. However, the JVM doesn't support useful features to scripting users, such as instruction counting (e.g. "only allow this function 250 steps before terminating it" etc). I have a feeling this changed a few weeks ago with the latest version of the Java VM (v5) which apparently added a LOT of extra features to peek and poke the internals of the JVM...might be worth checking out what you can do to it these days.

I've completed my general lexical and syntax analyzer by C++ for several weeks ago (they worked fair, i think). But I don't know how to compile to asm code (or bytecode...). Could you please told me where I should get info about this?