I am not so good with Makefiles, so I can see your point on that.
As far as dc, technically dc is not a standard, so if you
standards-conformant behavior, you need to write a bc that can operate
without dc. However, I will also be implementing dc in the same repo
someday. The question is which dc to implement.
About GNU extensions: this was originally implemented for toybox
(http://landley.net/toybox/), and the maintainer specifically asked
that my bc be able to run
which has basically every GNU extension. Thus, my bc will probably not
fit the suckless philosophy because the GNU extensions need to stay.
On Tue, Mar 13, 2018 at 1:36 PM, Laslo Hunhold <d...@frign.de> wrote:
> On Tue, 13 Mar 2018 12:30:40 -0600
> Gavin Howard <gavin.d.how...@gmail.com> wrote:
> Hey Gavin,
>> I was told that I should submit submit a link to my bc on this mailing
>> list. It's in alpha stage.
> based on the first look, it looks good. However, there are multiple
> things I have an issue with:
> - GNU extensions: This is a big no-no for me, as the entire point of
> sbase is to encourage standards-conformant behaviour. Most
> GNU-extensions are honestly rooted in a fundamental misunderstanding
> or lack of experience with tools, where one tool is extended to do
> the job of another tool.
> - Coding style: The Makefile uses GNU-extensions and the code itself
> lacks comments and proper indents (2-space-indents, seriously?).
> - Point: In general I don't see the point of implementing bc directly,
> given you can implement it as a dc script. Why don't you strip your
> codebase down, write a simple rpn-parser and use your general
> arithmetic to build something nice out of it? :) This way, you can
> also solve two problems at the same time (implementing dc(1) and
> bc(1) simultaneously).
> With best regards
> Laslo Hunhold
> Laslo Hunhold <d...@frign.de>