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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* aotto1968 <aotto1968@t-online.de>
| 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 {}
--<snip-snip>--
| var0 mng
| }

Well, you *could* do it in one step, but you don't have to ;-)

namespace eval ::funcDEF::MkErrN {
variable my
array set my {
RETURN_MAPPING {}
...
var0 mng
}
}

HTH
R'

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)