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

Subject: Re: [Boost-build] [future] Implementation language(s)..
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-10-25 14:00:14

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.
>> 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. 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.