Edi Weitz wrote:

> So, this function from Drakma
>
> (defun split-string (string &optional (separators " ,-"))
> "Splits STRING into substrings separated by the characters in the
> sequence SEPARATORS. Empty substrings aren't collected."
> (loop for char across string
> when (find char separators :test #'char=)
> when collector
> collect (coerce collector 'string) into result
> and do (setq collector nil) end
> else
> collect char into collector
> finally (return (if collector
> (append result (list (coerce collector 'string)))
> result))))
>
> works as intended with LispWorks, but doesn't work with AllegroCL or
> SBCL. It seems the latter two simply ignore the (SETQ COLLECTOR NIL)
> form. My guess is that the code above is somehow incorrect in that it
> modifies a variable which is used in a "collect ... into ..." clause,
> but I couldn't find anything in the CLHS that explicitly says so.
>
> Any hints?

In "ANSI Common Lisp", Paul Graham makes the following comments:

The loop macro was originally designed to help inexperienced
Lisp users write iterative code. Instead of writing Lisp code,
you express your program in a form meant to resemble English,
and this is then translated into Lisp. Unfortunately, loop is
more like English than its designers ever intended: you can
use it in simple cases without quite understanding how it
works, but to understand it in the abstract is almost
impossible.
....
the ANSI standard does not really give a formal specification
of its behavior.
....
The first thing one notices about the loop macro is that it
has syntax. A loop expression contains not subexpressions but
clauses. The clauses are not delimited by parentheses;
instead, each kind has a distinct syntax. In that, loop
resembles traditional Algol-like languages. But the other
distinctive feature of loop, which makes it as unlike Algol as
Lisp, is that the order in which things happen is only
loosely related to the order in which the clauses occur.
....
For such reasons, the use of loop cannot be recommended.

On Saturday, March 26, 2022 at 5:43:50 PM UTC-4, Robert L. wrote:
> Edi Weitz wrote:
>
> > So, this function from Drakma
> >
> > (defun split-string (string &optional (separators " ,-"))
> > "Splits STRING into substrings separated by the characters in the
> > sequence SEPARATORS. Empty substrings aren't collected."
> > (loop for char across string
> > when (find char separators :test #'char=)
> > when collector
> > collect (coerce collector 'string) into result
> > and do (setq collector nil) end
> > else
> > collect char into collector
> > finally (return (if collector
> > (append result (list (coerce collector 'string)))
> > result))))

> In "ANSI Common Lisp", Paul Graham makes the following comments:
>
> The loop macro was originally designed to help inexperienced
> Lisp users write iterative code. Instead of writing Lisp code,

Oh please! NO!

The loop macro was designed to make code easier to read, write, and maintain; why else would it be in the ANSI standard?

(defun split-string-on-char-loop (string char)
"Return list of substrings without any empty substrings."
(loop for start = 0 then (+ end 1)
for end = (position char string :start start)
unless (eq start end)
collect (subseq string start end)
until (null end)))

(defun split-string-on-char-do (string char)
"Return list of substrings without any empty substrings.
This function uses the [DO*] function."
(let ((res () ))
(do* ((start 0 (1+ end))
(end (position char string :start start)
;; end will have bad type reference
(position char string :start start)))
((null end)
(nreverse (push (subseq string start) res)))
(unless (eql start end)
(push (subseq string start end) res)))))

Seriously which is easier to read? The do loop has bad type inferences due to position returning null or a number.

I hope this is a descent example of loop. There are better ways to make the code easier to read. The thing with loop is that it is a macro, computers are fast enough these
days so that you do not have to use GOTO statements anymore :)

On 2022-03-30, steve gonedes <sgonedes1977@gmail.com> wrote:
> (defun split-string-on-char-loop (string char)
> "Return list of substrings without any empty substrings."
> (loop for start = 0 then (+ end 1)
> for end = (position char string :start start)
> unless (eq start end)
> collect (subseq string start end)
> until (null end)))

I've been amusing myself with a little light side project: cppawk.

It's combining C preprocessing with Awk.

The result is amazing (not in absolute terms, but relative to the
necessarily low expectations one would naturally have of this sort of
thing).

I've built a loop macro with definable clauses, that is capable
of parallel as well as cross-producting iteration---and with
a combinator that can parallelize clauses in the cross-producting loop.

Without further ado, here is a translation of your loop.

$ ./cppawk '
#include <iter.h>

// User-defined loop clause: first_then
// Five macros must be defined according a naming scheme,
// all having the same arguments.

#define __init_first_then(var, first, then) (var = (first))
#define __test_first_then(var, first, then) 1
#define __prep_first_then(var, first, then) 1
#define __fini_first_then(var, first, then) 1
#define __step_first_then(var, first, then) (var = (then))

// User-defined loop-clause: for_var
// Just macro for first_then
#define for_var(var, expr) first_then(var, expr, expr)

// index function with start position

function index_from(str, ch, start,
sstr, pos)
{ sstr = substr(str, start)
pos = index(sstr, ch)
return pos ? pos + start - 1 : 0
}

// now our loop

function split_string_on_char_loop(string, char)
{ loop (first_then (start, 1, end + 1),
for_var (end, index_from(string, char, start)),
xcollect (out, (end ? substr(string, start, end - start)
: substr(string, start))),
while (end))
{ }
return out
}

// Test with awk loop
// N.B.! the nil object is "" (empty string)
// sexp("") -> "nil"
{ print sexp(split_string_on_char_loop($1, $2)) }'
, ,
(nil nil)
a, ,
("a" nil)
,a ,
(nil "a")
a,b,c ,
("a" "b" "c")

I had to add the xcollect clause because the regular collect does not
fire when the loop terminates. If the loop body executes 3 times,
collect will produce a list of 3 items. But xcollect will also collect
the expression one more time in spite of the failed loop guard.

I will likely roll the user-defined first_then and for_var into
the implementation also.

Difference between collect and xcollect:

#define __init_collect(var, expr) var = list_begin()
#define __test_collect(var, expr) 1
#define __prep_collect(var, expr) var = list_add(var, expr)
#define __fini_collect(var, expr) var = list_end(var)
#define __step_collect(var, expr) 1

#define __init_xcollect(var, expr) var = list_begin()
#define __test_xcollect(var, expr) 1
#define __prep_xcollect(var, expr) var = list_add(var, expr)
#define __fini_xcollect(var, expr) var = list_end(list_add(var, expr))
#define __step_xcollect(var, expr) 1

In the "fini" operator, we do one extra list_add.

It sort of blows me away how simple everything is, in spite of the
weakness of the C preprocessor. It can't do anything; you can't
calculate the rest of an argument list or execute any sort of looping
or mapping. Yet ...

Other examples:

Find the maximum position of a ball thrown upward with initial
velocity 5. Velocity decrements by 1 on each step.

#include <iter.h>

BEGIN {
loop (from_step (vel, 5, -1),
from_step (pos, 0, vel),
while (pos >= 0),
maximizing (maxpos, pos))
{
print pos
}
print "maxpos =", maxpos
}'

0
4 7
9 10
10
9 7
4 0
maxpos = 10

Cross-product loop with parallel clauses thanks to the "lockstep"
clause combinator:

#include <iter.h>

BEGIN {
$0 = "a b c" # set fields

split("X Y", arr) # init array

bags (b1, b2) {
loop_cross (lockstep(fields(f),
str(i, ch, "IJK")),
keys(ky, arr),
lockstep(range(j, 1, 3),
from(k, 100)))
{
print f, ch, arr[ky], j, k
bag(b1, j)
}
}

print sexp(b1)
}

a I X 1 100
a I X 2 101
a I X 3 102
a I Y 1 100
a I Y 2 101
a I Y 3 102
b J X 1 100
b J X 2 101
b J X 3 102
b J Y 1 100
b J Y 2 101
b J Y 3 102
c K X 1 100
c K X 2 101
c K X 3 102
c K Y 1 100
c K Y 2 101
c K Y 3 102
(1 2 3 1 2 3 1 2 3 1 2 3 1 2 3 1 2 3)

Kaz Kylheku <480-992-1380@kylheku.com> writes:

> [ ... ]
> It's combining C preprocessing with Awk.

If there is one thing I could add to C it would be a better
preprocessor. I would not be using awk for this - I would probably write
it in C.