On 07/04/2016 11:48 AM, Lehmann, Patrick wrote: > I'm not implementing this feature, so it's not my choice, but Tcl is a > horrible language ;) > > I know it was originally designed as an embedded scripting language > especially for CAE > (EDA, CAD, ...) tools, but there are way better and easier embedded or > embeddable > scripting language available. For example: > - Python can be embedded in a few lines of C code. Its giving you access to a > very big > standard library and an easy to learn syntax. Having a Python interface > for GHDL > (longterm wish from me) could ease the handling of testbench interfaces > (Cocotb, > VUnit, ...) > - LUA is used in many projects under the hood as scripting and configuration > language. > See for example LuaTeX, Logitech keyboard scripting, ... > > Even a big EDA vendor is considering Python as new scripting interface... >
The feature-creep slippery-slope can be a fun [speculative] ride. Personally, I thought the light-weight [Jim]Tcl suggestion was a little excessive for the immediate need. The current design decision is: should a custom syntax and parser be developed for the signal-trace configuration file? (and ultimately, that's the decision of whoever writes something (open-source projects are grand)). An alternative approach, somewhere between a custom configuration file syntax/parser and an interpreted language, might be to use something like libconfig. http://www.hyperrealm.com/libconfig/libconfig.html In any case, documentation will probably be needed. If it already exists, that seems like a significant factor in the decision process. > So in my personal option: having a scripting interface could be a new big > feature for GHDL, > but Tcl would be my first and second choice. > Did you mean to say that Tcl would *not* be your first or second choice? (i.e., you do not like Tcl as a scripting/configuration syntax). _______________________________________________ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
