Re: using setq to create lists based on other lists...

[Rusi]

On Sunday, December 2, 2018 at 9:11:15 PM UTC+5:30, Jean-Christophe Helary 
wrote:
> > On Dec 3, 2018, at 0:07, Stefan Monnier  wrote:
> > 
> > Here's another take on it:
> > 
> >> If you do
> >> (setcar list0 0)
> > 
> > Why?  Just don't use setcar/setcdr!

That one line is succinct no doubt! Do you think its really comprehensible?

> 
> Lovely :)
> 
> When I check "Modifying Existing List Structure" the only things I find of 
> any use in my case are setcar/setcdr.
> 
> >> There are probably better ways to create lists based on other lists without
> >> "linking" the two, so I'd like some information about that.
> > 
> > The better way is to not modify the lists, so you're not affected by
> > whether they're linked or not.
> 
> I would certainly have considered that if I had known that setq was linking 
> the lists :)

And thats what I mean: "Lovely" ⇏ "Understood"!

More generally assignment ≠ mutation, especially in latent languages like 
lisp/python

By coincidence I was working on a sequel to my blog post:
http://blog.languager.org/2012/10/functional-programming-lost-booty.html
Out there I had tried to say: functional programming has nice *features* that 
may be used without using functional *languages*

Over time I am coming to see that there is an imbalance in the view in that 
post…

Niklaus Wirth said: The most important choices that a language designer makes
is what to leave out
Yeah that sounds like classical religious morality — the good person is the one
who has/enjoys/etc less.
And that is true — when programmers stopped ‘enjoying’ interrupts, registers, 
etc
we moved from assembly to (what was then called) hi-level programming

The same is true for FPLs — how to become more powerful by having less powerful
languages??

Here is my (as yet unfilled out) org ode list of these
"impoverishments that are enrichments"
Yeah they are probably not comprehensible as yet
For now I will just say that the second and third points are different:
assignment changes *variables*; mutability changes *constants*
(setq is assignment; set-car is mutation)

* Print Statement
* Assignment
* Mutability
* Pass-by malarchy
* Expressions AND Statements Syntax
* Void function
* Expressions AND Statements Semantics
* General typeless statement construction
* OOP (inheritance)

[My reason for posting this yet: Are there other unnecessarys of imperative/OO
programming that are 'irrelevantized' and thence removed in FPLS?
Would be interested to hear…

Sorry to Jean-Christophe if that is not very helpful
Here are my FP posts, admittedly mostly language neutral
http://blog.languager.org/search/label/FP