From: Douglas K. <do...@go...> - 2014-06-13 15:24:24
|
The description allows STRING not to allocate in the case of symbol or string input, so it seems to me that (string #\Newline) should not require a "#." in front of it in user code to obtain a constant string of one newline. And if through macroexpansion we end up with (string 'foo) this should be folded to "FOO". Sound ok? *Description:* Returns a *string* <http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_s.htm#string> described by *x*; specifically: - If *x* is a *string* <http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_s.htm#string>, it is returned. - If *x* is a *symbol* <http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_s.htm#symbol>, its *name* <http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_n.htm#name> is returned. - If *x* is a *character* <http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_c.htm#character>, then a *string* <http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_s.htm#string> containing that one *character* <http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_c.htm#character> is returned. - *string* <http://www.lispworks.com/documentation/HyperSpec/Body/f_string.htm#string> might perform additional, *implementation-defined* <http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_i.htm#implementation-defined> conversions. |
From: Stas B. <sta...@gm...> - 2014-06-13 17:35:56
|
Douglas Katzman <do...@go...> writes: > The description allows STRING not to allocate in the case of symbol or > string input, so it seems to me that (string #\Newline) should not require > a "#." in front of it in user code to obtain a constant string of one > newline. > And if through macroexpansion we end up with (string 'foo) this should be > folded to "FOO". > > Sound ok? > > *Description:* The issue is coalescing, (eql (string 'foo) "FOO") will change from NIL to T. Is that allowed? Is that expected? -- With best regards, Stas. |
From: Douglas K. <do...@go...> - 2014-06-13 17:55:47
|
interesting point. I think one could argue that the dumping/restoring of the second argument to EQL was permitted to find and return any symbol in the image that was similar-as-constant. So in fact the answer might have been T even if (string 'foo) was not compile-time folded. Your point holds even for the character-to-string-of-length-1 but all the same I think it's on firmer ground to fold (string #\a) => "a" because "returns a string" doesn't preclude that there might be a cache of single-character strings whose codes are in the range of base-char, and that the string could come from that cache. And that any one-character string appearing as a constant in code might also come from the cache. If nothing else, we should make (string "foo") an identity. On Fri, Jun 13, 2014 at 1:35 PM, Stas Boukarev <sta...@gm...> wrote: > Douglas Katzman <do...@go...> writes: > > > The description allows STRING not to allocate in the case of symbol or > > string input, so it seems to me that (string #\Newline) should not > require > > a "#." in front of it in user code to obtain a constant string of one > > newline. > > And if through macroexpansion we end up with (string 'foo) this should be > > folded to "FOO". > > > > Sound ok? > > > > *Description:* > The issue is coalescing, > (eql (string 'foo) "FOO") will change from NIL to T. Is that allowed? Is > that expected? > > -- > With best regards, Stas. > |
From: Stas B. <sta...@gm...> - 2014-06-13 18:00:43
|
Douglas Katzman <do...@go...> writes: > interesting point. I think one could argue that the dumping/restoring of > the second argument to EQL was permitted to find and return any symbol in > the image that was similar-as-constant. So in fact the answer might have > been T even if (string 'foo) was not compile-time folded. > > Your point holds even for the character-to-string-of-length-1 but all the > same I think it's on firmer ground to fold (string #\a) => "a" because > "returns a string" doesn't preclude that there might be a cache of > single-character strings whose codes are in the range of base-char, and > that the string could come from that cache. And that any one-character > string appearing as a constant in code might also come from the cache. > > If nothing else, we should make (string "foo") an identity. For make-string it also says "returns a simple string", but nobody would dare to fold that. -- With best regards, Stas. |
From: Douglas K. <do...@go...> - 2014-06-13 18:10:33
|
Right, but MAKE-anything is clearly a constructor. STRING is more like COERCE, and (lambda () (coerce '(1 2) 'list)) does not call coerce, it just returns the constant. Is the bottom line that you would agree or disagree with folding the single-character case? On Fri, Jun 13, 2014 at 2:00 PM, Stas Boukarev <sta...@gm...> wrote: > Douglas Katzman <do...@go...> writes: > > > interesting point. I think one could argue that the dumping/restoring of > > the second argument to EQL was permitted to find and return any symbol in > > the image that was similar-as-constant. So in fact the answer might have > > been T even if (string 'foo) was not compile-time folded. > > > > Your point holds even for the character-to-string-of-length-1 but all the > > same I think it's on firmer ground to fold (string #\a) => "a" because > > "returns a string" doesn't preclude that there might be a cache of > > single-character strings whose codes are in the range of base-char, and > > that the string could come from that cache. And that any one-character > > string appearing as a constant in code might also come from the cache. > > > > If nothing else, we should make (string "foo") an identity. > For make-string it also says "returns a simple string", but nobody would > dare to fold that. > > -- > With best regards, Stas. > |
From: Stas B. <sta...@gm...> - 2014-06-13 18:14:00
|
Douglas Katzman <do...@go...> writes: > Right, but MAKE-anything is clearly a constructor. > STRING is more like COERCE, and (lambda () (coerce '(1 2) 'list)) does not > call coerce, it just returns the constant. That's not comparable, (coerce '(1 2) 'vector) does create a vector. > Is the bottom line that you would agree or disagree with folding the > single-character case? And it's not only coalescing that is problematic: (setf (char (string #\a) 0) #\z) => Destructive function (SETF AREF) called on constant data. So, as you can guess, I'm against all folding, except for strings. -- With best regards, Stas. |
From: Pascal J. B. <pj...@in...> - 2014-06-13 20:10:17
|
Douglas Katzman <do...@go...> writes: > The description allows STRING not to allocate in the case of symbol > or string input, so it seems to me that (string #\Newline) should not > require a "#." in front of it in user code to obtain a constant > string of one newline. > And if through macroexpansion we end up with (string 'foo) this > should be folded to "FOO". > > Sound ok? > > Description: > > Returns a string described by x; specifically: > > If x is a string, it is returned. > If x is a symbol, its name is returned. > If x is a character, then a string containing that one character > is returned. > string might perform additional, implementation-defined > conversions. It doesn't say a "fresh" string containing that one character is returned. (string #\a) could be compiled as "a", since a CL compiler can open code any CL function. By the same token (string (the character x)) could be compiled as (gethash x *all-single-character-strings*), if the implementation deemed it worthwhile to do. -- __Pascal Bourguignon__ http://www.informatimago.com/ "Le mercure monte ? C'est le moment d'acheter !" |
From: Stas B. <sta...@gm...> - 2014-06-13 20:39:32
|
"Pascal J. Bourguignon" <pj...@in...> writes: > Douglas Katzman <do...@go...> writes: > >> The description allows STRING not to allocate in the case of symbol >> or string input, so it seems to me that (string #\Newline) should not >> require a "#." in front of it in user code to obtain a constant >> string of one newline. >> And if through macroexpansion we end up with (string 'foo) this >> should be folded to "FOO". >> >> Sound ok? >> >> Description: >> >> Returns a string described by x; specifically: >> >> If x is a string, it is returned. >> If x is a symbol, its name is returned. >> If x is a character, then a string containing that one character >> is returned. >> string might perform additional, implementation-defined >> conversions. > > It doesn't say a "fresh" string containing that one character is > returned. > > (string #\a) could be compiled as "a", since a CL compiler can open code > any CL function. > > By the same token (string (the character x)) could be compiled as > (gethash x *all-single-character-strings*), if the implementation deemed > it worthwhile to do. Is there a passage mandating the usage of the term "fresh"? Because the entry for the LIST function doesn't mention freshness. -- With best regards, Stas. |
From: Pascal J. B. <pj...@in...> - 2014-06-14 01:09:42
|
Stas Boukarev <sta...@gm...> writes: > "Pascal J. Bourguignon" <pj...@in...> writes: > >> Douglas Katzman <do...@go...> writes: >> >>> The description allows STRING not to allocate in the case of symbol >>> or string input, so it seems to me that (string #\Newline) should not >>> require a "#." in front of it in user code to obtain a constant >>> string of one newline. >>> And if through macroexpansion we end up with (string 'foo) this >>> should be folded to "FOO". >>> >>> Sound ok? >>> >>> Description: >>> >>> Returns a string described by x; specifically: >>> >>> If x is a string, it is returned. >>> If x is a symbol, its name is returned. >>> If x is a character, then a string containing that one character >>> is returned. >>> string might perform additional, implementation-defined >>> conversions. >> >> It doesn't say a "fresh" string containing that one character is >> returned. >> >> (string #\a) could be compiled as "a", since a CL compiler can open code >> any CL function. >> >> By the same token (string (the character x)) could be compiled as >> (gethash x *all-single-character-strings*), if the implementation deemed >> it worthwhile to do. > Is there a passage mandating the usage of the term "fresh"? > Because the entry for the LIST function doesn't mention freshness. List could be implemented as: (defun list (&rest list) list) which technically doesn't return a fresh list. It seems to me that you can't expect a call such as: (apply (function list) '(1 2 3)) to return something else than '(1 2 3). (let ((x (quote (1 2 3)))) (eq x (apply (function list) x))) --> true or nil If you want to ensure a fresh list, you will have to call COPY-LIST. -- __Pascal Bourguignon__ http://www.informatimago.com/ "Le mercure monte ? C'est le moment d'acheter !" |
From: Stas B. <sta...@gm...> - 2014-06-14 11:17:13
|
"Pascal J. Bourguignon" <pj...@in...> writes: > Stas Boukarev <sta...@gm...> writes: > >> "Pascal J. Bourguignon" <pj...@in...> writes: >> >>> Douglas Katzman <do...@go...> writes: >>> >>>> The description allows STRING not to allocate in the case of symbol >>>> or string input, so it seems to me that (string #\Newline) should not >>>> require a "#." in front of it in user code to obtain a constant >>>> string of one newline. >>>> And if through macroexpansion we end up with (string 'foo) this >>>> should be folded to "FOO". >>>> >>>> Sound ok? >>>> >>>> Description: >>>> >>>> Returns a string described by x; specifically: >>>> >>>> If x is a string, it is returned. >>>> If x is a symbol, its name is returned. >>>> If x is a character, then a string containing that one character >>>> is returned. >>>> string might perform additional, implementation-defined >>>> conversions. >>> >>> It doesn't say a "fresh" string containing that one character is >>> returned. >>> >>> (string #\a) could be compiled as "a", since a CL compiler can open code >>> any CL function. >>> >>> By the same token (string (the character x)) could be compiled as >>> (gethash x *all-single-character-strings*), if the implementation deemed >>> it worthwhile to do. >> Is there a passage mandating the usage of the term "fresh"? >> Because the entry for the LIST function doesn't mention freshness. > > List could be implemented as: > > (defun list (&rest list) list) Where does it say that it can be implemented in such a way? -- With best regards, Stas. |
From: Paul K. <pv...@pv...> - 2014-06-14 16:09:41
|
Pascal J. Bourguignon wrote: > List could be implemented as: > > (defun list (&rest list) list) > > which technically doesn't return a fresh list. [...] > If you want to ensure a fresh list, you will have to call COPY-LIST. You're welcome to move this conversation elsewhere. Standard compliance is necessary, but not sufficient. No one wins if programmers have to write code like (copy-list (list x y z)). Paul Khuong |
From: Peter S. <pe...@pj...> - 2014-06-14 16:55:56
|
On 14/06/14 17:09, Paul Khuong wrote: > Pascal J. Bourguignon wrote: >> List could be implemented as: >> >> (defun list (&rest list) list) >> >> which technically doesn't return a fresh list. > [...] >> If you want to ensure a fresh list, you will have to call COPY-LIST. > You're welcome to move this conversation elsewhere. Standard compliance > is necessary, but not sufficient. No one wins if programmers have to > write code like (copy-list (list x y z)). > > Paul Khuong Erm, I think you've misread it? As I read it, you would only need to use copy-list in the exceedingly narrow case (apply 'list '(1 2 3)), unless you were to memo-ise list, (which really would be a loss for everybody). > > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel |
From: Douglas K. <do...@go...> - 2014-06-13 21:00:29
|
But LIST's explanation uses the word "constructed" (twice) which couldn't be understood in any way other than creation of new objects. On Fri, Jun 13, 2014 at 4:39 PM, Stas Boukarev <sta...@gm...> wrote: > "Pascal J. Bourguignon" <pj...@in...> writes: > > > Douglas Katzman <do...@go...> writes: > > > >> The description allows STRING not to allocate in the case of symbol > >> or string input, so it seems to me that (string #\Newline) should not > >> require a "#." in front of it in user code to obtain a constant > >> string of one newline. > >> And if through macroexpansion we end up with (string 'foo) this > >> should be folded to "FOO". > >> > >> Sound ok? > >> > >> Description: > >> > >> Returns a string described by x; specifically: > >> > >> If x is a string, it is returned. > >> If x is a symbol, its name is returned. > >> If x is a character, then a string containing that one character > >> is returned. > >> string might perform additional, implementation-defined > >> conversions. > > > > It doesn't say a "fresh" string containing that one character is > > returned. > > > > (string #\a) could be compiled as "a", since a CL compiler can open code > > any CL function. > > > > By the same token (string (the character x)) could be compiled as > > (gethash x *all-single-character-strings*), if the implementation deemed > > it worthwhile to do. > Is there a passage mandating the usage of the term "fresh"? > Because the entry for the LIST function doesn't mention freshness. > > -- > With best regards, Stas. > > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > |
From: Stas B. <sta...@gm...> - 2014-06-13 22:58:59
|
Douglas Katzman <do...@go...> writes: > But LIST's explanation uses the word "constructed" (twice) which couldn't > be understood in any way other than creation of new objects. This is getting too silly. "It says constructed, but it doesn't say when, it could have been done earlier or reused." -- With best regards, Stas. |
From: Pascal J. B. <pj...@in...> - 2014-06-14 14:02:05
|
Stas Boukarev <sta...@gm...> writes: > "Pascal J. Bourguignon" <pj...@in...> writes: > >> Stas Boukarev <sta...@gm...> writes: >> >>> "Pascal J. Bourguignon" <pj...@in...> writes: >>> >>>> Douglas Katzman <do...@go...> writes: >>>> >>>>> The description allows STRING not to allocate in the case of symbol >>>>> or string input, so it seems to me that (string #\Newline) should not >>>>> require a "#." in front of it in user code to obtain a constant >>>>> string of one newline. >>>>> And if through macroexpansion we end up with (string 'foo) this >>>>> should be folded to "FOO". >>>>> >>>>> Sound ok? >>>>> >>>>> Description: >>>>> >>>>> Returns a string described by x; specifically: >>>>> >>>>> If x is a string, it is returned. >>>>> If x is a symbol, its name is returned. >>>>> If x is a character, then a string containing that one character >>>>> is returned. >>>>> string might perform additional, implementation-defined >>>>> conversions. >>>> >>>> It doesn't say a "fresh" string containing that one character is >>>> returned. >>>> >>>> (string #\a) could be compiled as "a", since a CL compiler can open code >>>> any CL function. >>>> >>>> By the same token (string (the character x)) could be compiled as >>>> (gethash x *all-single-character-strings*), if the implementation deemed >>>> it worthwhile to do. >>> Is there a passage mandating the usage of the term "fresh"? >>> Because the entry for the LIST function doesn't mention freshness. >> >> List could be implemented as: >> >> (defun list (&rest list) list) > Where does it say that it can be implemented in such a way? In the dictionary, under the definition of "could", vs. "have to". -- __Pascal Bourguignon__ http://www.informatimago.com/ "Le mercure monte ? C'est le moment d'acheter !" |
From: Pascal J. B. <pj...@in...> - 2014-06-14 17:17:01
|
Paul Khuong <pv...@pv...> writes: > Pascal J. Bourguignon wrote: >> List could be implemented as: >> >> (defun list (&rest list) list) >> >> which technically doesn't return a fresh list. > [...] >> If you want to ensure a fresh list, you will have to call COPY-LIST. > > You're welcome to move this conversation elsewhere. Standard compliance > is necessary, but not sufficient. No one wins if programmers have to > write code like (copy-list (list x y z)). This is not necessary. But: (values (delete 2 (copy-list (apply (function list) '(1 2 3)))) '(1 2 3)) would definitely need the copy-list to be conforming, IMO. -- __Pascal Bourguignon__ http://www.informatimago.com/ "Le mercure monte ? C'est le moment d'acheter !" |