Re: tcl hidden "cruelties"

On 10/10/2024 11:20, aotto1968 wrote:

Hi,
 I am in the process of rewriting my ALC compiler, whereby the back-end is being rewritten from "tabular" to "object-oriented".
 Both types of structures have their advantages and disadvantages. The "tabular" structure is suitable for cross-object analysis and the "object-oriented" structure is suitable for object-specific analysis.
 Unfortunately, you can only ever use ONE type of data structure, so I now use the "tabular" structure in the FRONT-END and the "object-oriented" structure in the BACK-END.
 Anyone who knows TCL knows that "refactoring" TCL code is cruel, because it always ends in a huge amount of "broken" code.
 Regardless of "broken code", TCL itself has some cruelties in its syntax. Here, for example, the storage of an "array" with a namespace path, which in TCL always has !! TWO !! commands. ONE command to generate the namespace and ONE command to finally generate the array.
 namespace eval ::funcDEF::MkErrN {}
array set ::funcDEF::MkErrN::my {
     RETURN_MAPPING                                     {}
     argv                                               {{ME_CXN_MK_MNGN mng}}
     class                                              MkErrorC
     classC                                             MkErrorC
     classM                                             ME_CCC_MkErrorC
     func                                               MkErrN
     prefix                                             Class
     prefixC                                            ClassC
     prefixM                                            ME_CCC_MkErrorC
     retC                                               MkErrorC
     retM                                               ME_CCN_MkErrorC
     retOM                                              ME_CCN_MkErrorC
     ty                                                 sm_
     type0M                                             ME_CXN_MK_MNGN
     var0                                               mng
}
 mfg

You are absolutely correct. Choice of data structure, programming style and programming language is always a compromise. If we are lucky, time shows that the choices we made were the right ones, for us and for the job in hand.
Often things prove otherwise, and we are faced with the choice between reworking everything to change the choices we made previously that we now view as mistakes, or to accept that some things are more difficult than they might have been and persevere down the route we chose previously.
As previously we make a choice and in time we can form a view as to whether we made the right or wrong choice.
In my experience it's never profitable, or helpful, to spend much time mourning or moaning about the choices we make. Review them, by all means; if we've made the wrong choice try to determine why we made that choice and resolve to choose better next time. It's the only way!
besten gruesse