On Tue, Mar 13, 2018 at 12:36 PM, Laslo Hunhold <dev_AT_frign.de> wrote:
> - 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).
Do you have a source for standardized dc? This list of utilities[0]
for 2004 edition does not include dc.
Yes it was historical practice to implement bc as a single yacc file
that compiled bc to dc and piped it through dc. This is very difficult
to do correctly. Even if you have a dc that does proper tail call
elimination (I do[1]), compiling bc to dc in such a way as to take
advantage of that is difficult. For an example try an infinite loop in
9base bc. You get stack overflows in dc.
POSIX bc is severely limited. That's why it's so rare to see scripts
that don't use extensions. I just sent another reply talking about
those so I won't repeat myself here.
I think that bc with extensions like variable names and print is
better than and will be used more than a minimally POSIX compliant bc.
I also think that dc is dead. Although it's fun to implement and play
around with, it was removed from POSIX for a reason: it's esoteric and
basically useless in the face of bc.
(Note: My dc implementation is far from finished. It uses doubles and
doesn't do any base conversion. I got distracted hacking away at an
interactive rpn calculator so I don't have to keep my 15c on my desk
at work. Be warned that the ic code is crap. While I plan to implement
bc twice, once as a compiler as mentioned and once stand alone, I
haven't started either.)
[0]
http://pubs.opengroup.org/onlinepubs/009695399/utilities/bc.html
[1]
https://bitbucket.org/emg/bc
Received on Thu Mar 15 2018 - 19:05:26 CET