Re: implementation language [was: library for unicode collation in C for texi2any?]

[Leo Butler]

On Mon, Oct 16 2023, Per Bothner <per@bothner.com> wrote:

> On 10/16/23 05:36, Gavin Smith wrote:
>> On Sun, Oct 15, 2023 at 12:00:51PM -0700, Per Bothner wrote:
>>> I'm far from a C++ expert these days, but some ideas:
>>>
>>> * First of course you can define some helper methods:
>>>
>>> class TargetElement {
>>>    Extra *extra;
>>>    Command *unit_command() { return extra ? extra->init_command() : 
>>> nullptr; }
>>> }
>> I don't think you can implement this language feature with helper
>> methods, at least not like this.  Consider the chain of access
>> a->maybe_b()->maybe_c()->d().  If maybe_b() returns null then the ->maybe_c()
>> call will be an error
> I just meant for the more common cases it might be reasonable to add
> some helper methods. It's a case-by-case approach, not a general one.
>
> For example if a->maybe_b()->maybe_c()->d() occurs multiple times
> it might make sense to add a maybe_d method to A's class.
>
>> It's still more verbose.
>> ...
>> This would require a lot of extra class definitions and doesn't seem that
>> easy to read.
>
> Regardless, C++ has more tools than C does to deal with with these issues.
> Which is my point: if you're using C, you might as well use a C++ compiler.
> Then you can decide which C++ features to use, as you go along.
> No need to aim for full-blown idiomatic C++. C with some C++ features is OK 
> too.

This is an interesting thread.

I have often wondered why the documentation language of the GNU project
has its translator implemented a language that is not part of the GNU
project. Guile-scheme, in particular, seems to have the features you
want.

Leo