On Tue, Mar 13, 2018 at 12:36 PM, Laslo Hunhold <[email protected]> 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
