Re: About how to initialize in LOOP

Hi,

> *  <[email protected]> [2017-12-21 16:47:12 +0000]:
>
> [I'v been much more involved with specifications than actual code in
> recent years.  And it shows...]

;-)

My problem with your proposal is that you do not offer the code what
works / breaks with each proposal.
IOW, you think in terms "how do we macroexpand various LOOP forms and
what behavior can be expected from such approaches".
I think in terms "how the code is expected to behave from the user POV",
ignoring mental macroexpand.

Let us start with code samples and what they should return, not with
"how we should macroexpand LOOP".

Standards and specs codify user expectations.
Implementing behavior that surprises a reasonable user is not a good
idea from the usability POV.

> As the discussion around issue 222 shows, the committee did not reach
> a consensus, to the texts were not changed. The ancient MIT LOOP
> implements this behaviour.

For a good reason...
(and the committee did not reach a consensus because implementing this
behavior is relatively hard and the maintainers of existing
implementations do not want to bear the costs).

Note that it is unclear how do implement it in a way that things like
these behave as the user expects:

(let ((x '(a b c d)))
  (loop repeat 2 for x in x collect x))
==> (a b)

(let ((x '(a b c d)))
  (loop for x from 1 to 2 for y = x collect y))
==> (1 2)

> (loop for a = (princ 1) then b for b below (princ 2) do (princ (list a b)))
> would print 21 by that proposal.

This behavior does not stand the WTF test.

> (loop for vars on vars for x = (error) then 2 return vars) would not error out.

if VARS is bound to non-NIL, this does not stand the WTF test.

>  - Disallows LOOP-FINISH within INITIALLY, as the (GO epilogue) tag is not visible.
>    But if you need to exit that early, why not use (RETURN-FROM named x)?

No, people expect this.

> (LOOP FOR a = (princ 1) FOR vars ON (princ vars) RETURN (list a b))
> would expand to something containing
> (let ((A nil))
>   (flet ((#:on-init () (princ VARS)))
>     (let ((VARS nil))
>       (tagbody ... (setq A (princ 1)) (setq VARS (#:on-init)) ...))))

This looks suspiciously like lasy-let ;-)

> Live with bug #667 and bug #375 and a few others I've not yet written about.

No, these bugs violate user expectations.

I must admit that I did not study your proposals in detail yet, but it
would be nice if you could augment it with actual code:


> | Case \ Proposal       | 1:INIT-FORM | 2:FIRST      | 3:FLET  | 4:QUO       |
> |-----------------------+-------------+--------------+---------+-------------|
> | vars on vars          | yes         | yes          | yes     | no          |
> | form1 in lex. env.    | no          | yes          | yes     | yes         |
> | left to right         | strict      | except first | strict  | strict      |
> | ready in initially    | yes         | yes          | yes     | interleaved |
> | initially interleaved | compatible  | compatible   | ?       | yes         |
> | overhead              | lowest      | low          | highest | middle      |

The descriptions are not very clear.
Could you please give code snippets and their behaviors for each proposal?

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net https://jihadwatch.org
http://islamexposedonline.com http://www.memritv.org http://think-israel.org
Professionalism is being dispassionate about your work.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel