John McKown wrote:
>Well, I understand your comments on DFSORT's control language. ICETOOL +
>SYMNAMES does a lot to enhance DFSORT.
Indeed. ICETOOL is my friend.
>But a more "general purpose" language, building on these, might be nice.
Agreed. I look at what is available, how that is suit
On Mon, May 16, 2016 at 7:23 AM, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:
> John McKown wrote:
>
> >> You can always write a 3rd SORT system with a build in programming
> language. Hopefully that system is sort of free...
>
> >Oh, yeah. Perhaps based on Guile (big grin)
> >htt
John McKown wrote:
>> You can always write a 3rd SORT system with a build in programming language.
>> Hopefully that system is sort of free...
>Oh, yeah. Perhaps based on Guile (big grin)
>https://en.wikipedia.org/wiki/GNU_Guile. It's a LISP variant.
H, very very interesting part of the GN
On Mon, May 16, 2016 at 4:31 AM, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:
> Peter Hunkeler wrote:
>
> >Not sure whether I shall laugh or cry. DFSort is a great tool, no doubt;
> it's control statements (I intentionally don't called it "language") are a
> nightmare, no doubt. Ho
Peter Hunkeler wrote:
>Not sure whether I shall laugh or cry. DFSort is a great tool, no doubt; it's
>control statements (I intentionally don't called it "language") are a
>nightmare, no doubt. Hopefully noone will ever consider the above as something
>suitable for production. Overkill; not mai
>So, changed those to non-printable. That would fix it up, but the code is
>still suffering from having to change >horses in mid-stream. And there's the
>fat-fingering, which is an all-too-common issue.
>
>Leads to sort symbols, WHEN=INIT, two FINDREPs with STARTPOS and DO=1 and
>SHIFT=NO.
>
>
