Re: designing language extensions, was Looking for volunteers for XL

On 2011-12-01, Kaz Kylheku <kaz@kylheku.com> wrote:
>> Take the well-known language C, which has a crude mechanism to extend
>> it in the form of its pre-processing macro language.
>>
>> Most enhancements you might want to make to the language, can be
>> achieved by some clunky, ugly macro. But the real problem is that your
>> code now consists of a private, ad-hoc collection of macros which
>> no-one else understands.
>
> That isn't the problem, because collections of macros can be
> well-designed, implemented and documented,


So can brainf*ck code :-) A faulty language doesn't precluding
investing an huge amount of engineering, testing and
adminstration/documentation to manage it.


But that doesn't meant that all languages should be faulty :-)


> Not all the problems in the C preprocessor are in the preprocessor. Never mind
> that all it can do is substitute, arguments, paste tokens. produce strings,
> and suck in include files.


Well, that is what (pure) preprocessors do? :-)


If you start adding more knowledge to the preprocessor it becomes a
part of the compiler and language, and your macros are not true macros
anymore, but inlinable functions.


> One big problem is that the target language for macro expansions (C)
> sucks. For one thing, any syntactic unit that contains declarations
> cannot be an expression that returns a value.


I would write that up to keeping the preprocessor mostly a text
manipulator rather than a compiler, not a target language defect.


A preprocessor that fully understood what it was parsing could hoist
such declarations out of the block if the language needed it?


> Macros that need to generate complex code that requires hidden variables
> automatically have a difficulty in returning a value in a
> function-call-like way, because only expressions do that. Macros do not
> work well over languages that don't have a uniform syntax that corresponds
> well to the implied abstract syntax trees.


I think this is a symptom of the above. A simple hierarchical
structure is easier to duplicate between preprocessor and compiler,
but it is the barriers that are are part of the definition (separate
binary, textual substitution) that are the main problems.

Return to the comp.compilers page.
Search the comp.compilers archives again.