LAST CALL for SRFI-113, Sets and bags
John Cowan
(16 Aug 2014 00:23 UTC)
|
Re: LAST CALL for SRFI-113, Sets and bags
Michael Sperber
(16 Aug 2014 14:11 UTC)
|
Re: LAST CALL for SRFI-113, Sets and bags
John Cowan
(16 Aug 2014 18:16 UTC)
|
Re: LAST CALL for SRFI-113, Sets and bags
Per Bothner
(16 Aug 2014 20:33 UTC)
|
Broken SRFI 113 title
John Cowan
(16 Aug 2014 23:19 UTC)
|
Re: LAST CALL for SRFI-113, Sets and bags
Kevin Wortman
(18 Aug 2014 22:11 UTC)
|
Re: LAST CALL for SRFI-113, Sets and bags
John Cowan
(18 Aug 2014 22:38 UTC)
|
Re: LAST CALL for SRFI-113, Sets and bags
Per Bothner
(18 Aug 2014 22:42 UTC)
|
Re: LAST CALL for SRFI-113, Sets and bags
Kevin Wortman
(18 Aug 2014 22:57 UTC)
|
Re: LAST CALL for SRFI-113, Sets and bags
John Cowan
(19 Aug 2014 00:26 UTC)
|
Re: LAST CALL for SRFI-113, Sets and bags
Kevin Wortman
(19 Aug 2014 17:57 UTC)
|
Re: LAST CALL for SRFI-113, Sets and bags
John Cowan
(19 Aug 2014 18:18 UTC)
|
Re: LAST CALL for SRFI-113, Sets and bags
Kevin Wortman
(19 Aug 2014 21:15 UTC)
|
Re: LAST CALL for SRFI-113, Sets and bags
John Cowan
(19 Aug 2014 22:20 UTC)
|
Re: LAST CALL for SRFI-113, Sets and bags
Kevin Wortman
(20 Aug 2014 06:44 UTC)
|
Re: LAST CALL for SRFI-113, Sets and bags John Cowan (20 Aug 2014 13:28 UTC)
|
Kevin Wortman scripsit: > I think the alist conversion procedures are important since they allow bags > to be defined in program text and serialized with read and write. I agree, and there is no question of flushing bag->alist or alist->bag. It's only alist->bag! whose consistency and utility I'm beginning to question. > I guess the pertinent question is: does ((a . 1) (1 . 2)) mean (1) "1 copy > of a, and then *an additional* 2 copies of a"; or (2) "currently the count > of a's is 1; in the past the count for a was 2." The semantics of assoc > make it seem that conventionally, (2) is how alists with duplicate entries > are interpreted. Which I think is consistent with your first definition for > how alist->bag and alist->bag! should work. I agree that assoc semantics should dominate, and all entries after the first should be ignored. The question then is: given an implicit bag defined by an alist with duplicate entries ignored, what is the semantics of merging this into an existing bag? Is it union or sum or replacement? It's not obvious to me that either semantics is a clear winner. So perhaps we should only standardize alist->bag, and leave bag merger to the user. This also suggests that we need a procedure bag-sum(!), with semantics {a, a, a} + {a, a} = {a, a, a, a, a}. The current definition of bag-union gives {a, a, a} on the assumption that the elements are indistinguishable, whereas bag-sum would treat them as distinguishable. Checking Wikipedia s.v. Multiset, I find that sum is defined precisely this way, as well as scalar product: {a, a, a} x 2 = {a, a, a, a, a, a}. Lastly, I think we should have cartesian product of both sets and bags. I don't know how I came to overlook it before, probably because none of the other libraries I have looked at (Scheme, Lisp, Python, Haskell, etc.) have given it. It is a fundamental set operation, however. I'll assume that the tuples (a,b) in the product should be represented in Scheme as (a b), unless someone has strong contrary feelings. -- John Cowan http://www.ccil.org/~cowan xxxxxx@ccil.org "The exception proves the rule." Dimbulbs think: "Your counterexample proves my theory." Latin students think "'Probat' means 'tests': the exception puts the rule to the proof." But legal historians know it means "Evidence for an exception is evidence of the existence of a rule in cases not excepted from."