Re: [Boost-build] [future] Implementation language(s)..

Subject: Re: [Boost-build] [future] Implementation language(s)..
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2016-10-25 14:09:34

On 25.10.2016 14:00, Klemens Morgenstern wrote:
> Am 25.10.2016 um 18:59 schrieb Stefan Seefeld:
>> On 25.10.2016 12:36, Paul A. Bristow wrote:
>>> I've been watching this conversation with interest (and am impressed
>>> by your enthusiasm).
>>>
>>> Before you go too far down the using Python route, may I be so bold
>>> as to ask if are you quite sure that you can't do the whole task
>>> in C++?
>> I'm sure it's possible (especially for some Boost enthusiast ;-) ) to
>> write an entire build system (including makefiles) in C++. But I'm also
>> sure that I don't want makefiles that are C++ source code. :-)
>>
>> Unless of course you were thinking of using one of the Boost parsers
>> (spirit, proto, etc.) to define a new language to be used for makefiles,
>> which would put us back to square one, and which I'd be violently
>> opposed to (please no new language !!).
> I'm actually for that - a utterly simple, jam-like language that is
> just for declaring targets, and maybe some conditionals. I'll even
> write the parser. Imho using a programming lanuage for target
> declarations is a bad idea, the languages are not made for that, which
> turns the build-definitions into unreadable messes. I really like bjam
> for that reason: it may be hard to write at times, but it's quite easy
> to read. So bring on the violence! :)
> I actually thought that was sort-of agreed upon, not sure that's the
> actual debate here (hence the topic is called "Implementation
> language(s)").
>
>>
>>> Every extra tool and plugin adds complexity - and loses you users,
>>> some before they start, and potentially many more when it doesn't
>>> 'just work'.
>> I think you are making up a false dichotomy here: While "extra tool"
>> sounds intuitive, the question is what the real alternative to using
>> such extra tools would be. Please don't let the Not Invented Here
>> syndrome strike yet again.
> And we have to presume that the build system can never do everything 
> a user might need, so we need extensibility anyway.

Aren't you contradicting yourself here ? Above you say "using a
programming lanuage for target declarations is a bad idea", and now "we
need extensibility anyway.", unless you envision two distinct languages
/ tools for these.

>>> Do you *really, really* need Python?  Are you quite sure that
>>> because that is your favorite tool, the task isn't a nail ;-)  There
>>> are a lot more C++ (including Boost) tools for writing DSL languages
>>> than were available when bjam was conceived and created.
>>>
>>> Just asking...
>> It's a good question. I think a key point is what we mean by "DSL
>> languages". To what degree are we talking about an entirely new language
>> here (including new syntax an new semantics) ? I'm really opposed to
>> defining a new language (as would be necessary when using C++ only).
>> When I talk about an embedded DSL inside Python I'm talking about
>> something really minimal that can be picked up easily by anyone, which
>> still reuses most of the semantics of the "host" language.
>>
> I'd be skeptical with that approach, because I fear that such a
> language will always end up more complex then anticipated.

...which is precisely why I'm favouring an existing language with a
track record of wide usage.

> If we have a DSEL it would necessarily grow into something weird
> (judging by my experience with boost.spirit), while a custom language
> (again, similar to jam) would be more extensible in syntax.
> Though I have to be fair: I know DSLs in C++, I got no idea how that
> would look in python. I'd be really interested to see what you have in
> mind.

Perhaps we need a prototype indeed...

        Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...