Re: RFCAS - Configuration segments in the San language
From: Nick Landsberg (SPAMhukolauTRAP_at_SPAMworldnetTRAP.att.net)
Date: 07/06/04
- Next message: Dan Tex1: "Re: OOP and memory management"
- Previous message: xarax: "Re: Null pointers in C, was What computer language is used a lot in the IT industry?"
- In reply to: Richard Harter: "Re: RFCAS - Configuration segments in the San language"
- Next in thread: Richard Harter: "Re: RFCAS - Configuration segments in the San language"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 06 Jul 2004 14:14:10 GMT
Richard Harter wrote:
> On Mon, 05 Jul 2004 22:39:32 GMT, Nick Landsberg
> <SPAMhukolauTRAP@SPAMworldnetTRAP.att.net> wrote:
>
>
>>Richard Harter wrote:
>>
>>>The San language (currently under development) does not use the
>>>"include file" mechanism (which your servant regards as being an
>>>unsavory archaism) nor the use/with scheme for providing for
>>>conditional code et al. Instead a San file is divided into major
>>>blocks called segments, the principal ones being configuration
>>>segments and code segments.
>>>
>>>The intent of the proposed scheme is to avoid the dragging in of
>>>large amounts of irrelevant text (as include files are wont to do) and
>>>at the same time provide for the possibility of configuration
>>>management in an orderly fashion. Below I have given an overview of
>>>the proposed scheme. Comments and suggestions are solicited.
>>>
>>>============
>>
>>[ SNIP FOR NOW ]
>>
>>Richard,
>>
>>I've just scanned your post, not digested it.
>>
>>It would help me immensely if you would be more
>>explicit with "what's the problem you're trying
>>to solve?" And then, possibly in parenthetical
>>remarks in the various sections, describe how
>>your proposed solution and/or the specific
>>constructs help to solve the problem.
>
>
> Sorry, I had supposed (quite erroneously it seems) that I had been
> fairly clear. However some essential background may well be needed.
> As background then:
>
> San is a new language that I am developing the specifications for. A
> San source file is divided into major sections called segments. There
> are different types of segments, the ones of interest being
> configuration segments and code segments. The configuration
> segment(s) roughly play the role of the C preprocessor and the include
> file in that it defines constants in the code, provides a means for
> finding source code in other files, and providing conditional
> compilation/interpretation (think #ifdef ... #endif). TWhat tWhhese
> are issues that come up in many languages with various methods used
> for handling them. Thus Ada has a with/use scheme (I can never
> remember which is which) in which you include the name of a package in
> the code and then access routines in the package.
>
> Unlike the C preprocessor San configuration directives do not appear
> in the San source code. Constants can be defined, e.g., the ever
> popular PI, and the source code can contain the names of dictionaries
> to search for the definition of names. In this regard there are two
> salient features - every identifier is bound to a San object, and all
> objects and identifiers have local scope. The role of dictionaries is
> to provide paths to definitions for unresolved identifiers.
>
> What, then, are the problems being solved? One is that the C
> preprocessor (and related diseases) is an ugly and unfortunate method
> for handling some rather common problems. Thus:
>
> (1) Including header files brings in vast amounts of irrelevant code.
> This not only makes for inefficiency in the compilation and in reading
> the code, it also makes for namespace problems.
>
> (2) Header files are included as incomplete path names (using
> syntactical tricks) that are resolved using the magic of environment
> variables. In cosnequence the entire system of header files has to be
> packaged in a predefined manner. This approach is cumbersome, rigid,
> and does not work well with code supporting alternate features.
>
> (3) Code macros are (IMNSHO) a blight. The C version is particularly
> unfortunate because of (a) the raw textual substitution, and (b) the
> differences in syntax between the preprocessor and the language.
> There are better macro languages; however there are syntax issues
> whenever the macro language and the code language differ.
>
> (4) Inserting conditional code directives in the midst of source code
> is a particularly unfortunate way to handle the conditional code
> issue. It makes the code less readable and it duplicates conditionals
> across routines. Adding new features or supported platforms can be
> ugly.
>
> Etc.
>
> These (mis)features have legitimate purposes. We don't want all of
> the source code (including all of the definitions) all in one file so
> we need some method for connecting all of the source files (including
> all of the definition files) together. We need something like include
> files.
>
> We need (or at least ardently desire) the ability to define common
> parameters once only.
>
> We need (even if we don't think we do) the ability to turn features on
> or off and to select code choices depending on platform or version.
>
> The San configuration methodology is supposed to supply a clean and
> coherent way to meet these needs, a way that provides a clean
> separation between configuration management and code, and a way that
> can handle wide variations in the support environment.
>
> Is this any help?
>
>
Yes Richard, very much so, thank you.
The administration and maintenance of a code base
spanning multiple releases, for possibly multiple
hardware platforms, with possibly certain customer-specific
features (which must only be delivered to that one customer)
etc. can be a huge headache on larger projects.
Now I'll look into it with much more than
just academic interest. :)
NPL
>
>
> Richard Harter, cri@tiac.net
> http://home.tiac.net/~cri, http://www.varinoma.com
> Whoever said money can't buy happiness
> didn't know where to shop.
-- "It is impossible to make anything foolproof because fools are so ingenious" - A. Bloch
- Next message: Dan Tex1: "Re: OOP and memory management"
- Previous message: xarax: "Re: Null pointers in C, was What computer language is used a lot in the IT industry?"
- In reply to: Richard Harter: "Re: RFCAS - Configuration segments in the San language"
- Next in thread: Richard Harter: "Re: RFCAS - Configuration segments in the San language"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
