True. The above was just to see if I'm correctly interpreting SICP flatmap. To make it a set one may e.g. insert for example. Or check if GCD = 1 with every fraction calculated:
(using GCD from the APL library, plus the weird but convenient map over keep from map over stream block )
Uhhhh, if you were taking the rational numbers themselves, but taking, say, 1/2 and 2/4 and saying they are UNIQUE, even though they REPRESENT the same number, then it's still a set. In fact, Cantor's diagonal argument USES DUPLICATES(1/1, 2/1, 1/2, 1/3, 2/2, 3/1, ...)
e.g. 1/2 and 2/4 are different representations of the same number; so ...
depending on the perspective (form vs. value) they can either both be separate members of a set, or they must be considered the same member;
I lean towards considering the Rationals a set of values, but I fully understand the alternative perspective;
In the end, what counts (granted, a corny pun) is that either way the Rationals are countable; it doesn't matter by which index number each Rational is referred to.
Getting back to logic programming and SICP section 4.4 ... since, as I have understood, Snap! 's list and Scheme's pair are somewhat different, how would:
(cons variable value)
(par. 4.4.4.8)
... translate to Snap! ?
, or
, or even
i think I have found the solution myself: it’s up to me to decide - as long as I’m consistently adhering to the same structure.
Yeah, you can do it however you want. But you're a little constrained by the fact that IN FRONT OF will only accept a list as its second input, whereas cons lets you put anything in the cdr. So for example a point on the plane which would naturally be (cons xposition yposition) in Lisp would have to be (LIST ...) in Snap!. If the list is stored as a Lisp-style linked list, that'd be two pairs rather than just one.
No, because that's not invertible. It has to be that
(car (cons a b)) = a
(cdr (cons a b)) = b
and that doesn't work for cdr, because if you see (list a (list b)) you don't know whether its cdr is supposed to be b or (list b).
No. That was a decision made in Scratch long ago, which we haven't, so far anyway, seen fit to change. I think that if we were ever to introduce pair mutation (SET ALL BUT FIRST OF _ TO _) (note the imperfect tense!), we might consider non-list pairs at the same time. Neither is very likely.
OK. Then I guess the only feasible general translation of a LISP / Scheme pair is a Snap! list of two items, while LISP / Scheme's list would translate to building nested 2-item lists in Snap!, much like the structure of streams. Is that right?
I was also puzzled by lambda (v f), but I think I know what it stands for now: the lambda function is an unbound variable handler that will ignore its second input - please correct me if I'm wrong.