On Nov 28, 2007 2:47 AM, Pau Garcia i Quiles <[EMAIL PROTECTED]> wrote: > > As "DSL based on Lua" != Lua, assuming Kitware gets rid of > documentation and bugs in the language might be too optimistic. Look > for example at RHDL (http://rhdl.rubyforge.org/): it's a Ruby-based > DSL for hardware description, like Verilog or VHDL, but it's so > different from Ruby you need to produce the whole documentation again.
So? So far I'm the only person who has proposed changing Lua syntax. I've only listed 2 items: excessive quotes and unpack(table). Nothing would stop anyone from using quotes all over the place or unpack(table), i.e. standard Lua would still work. It may even be possible for these minor tweaks to be transparently corrected as far as 3rd party Lua libraries are concerned. If it's 95% Lua it's still Lua. We're talking about a 1 page addendum to the docs, tops. > Talking about Ruby, could someone please paste his wishlist about > variable scoping for CMake? (ie what would you like to add: local > variables which die when you exit the loop, file-scoped variables, > directory-scoped variables, project-scoped variables, what?). It's > quite difficult to fix a problem we have not properly defined (at > least, I have never seen a proper wishlist about this). I just want scope, i.e. I don't want global variable names crapping all over each other. I don't care about any fancy dancy Computer Science ways of adding extra programmatic features. Other people may see heavy duty OO or tweaky FP constructs as beneficial for their build system. At present I don't. But there's clearly a need for more structure than CMake script has got. As far as I'm concerned the fancy dancy stuff is just an artifact of the embedded language that you get "for free," whether it's Lua, Ruby, or Python. None of that has been enough to propel SCons into the limelight. We already had the extended discussion about possible CMake scope implementations, so I'm not understanding what you're asking. I assumed that Kitware is ready to act when they have time to do so. Did you miss that discussion? Did it leave you with a bunch of unresolved questions? If so, I'd suggest going back into the archive and responding to specific things you're unclear about. Cheers, Brandon Van Every _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
