You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(19) |
Jul
(96) |
Aug
(144) |
Sep
(222) |
Oct
(496) |
Nov
(171) |
Dec
(6) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(4) |
Feb
(4) |
Mar
(9) |
Apr
(4) |
May
(12) |
Jun
(6) |
Jul
|
Aug
|
Sep
(1) |
Oct
(2) |
Nov
|
Dec
|
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(52) |
Aug
(47) |
Sep
(47) |
Oct
(95) |
Nov
(56) |
Dec
(34) |
2003 |
Jan
(99) |
Feb
(116) |
Mar
(125) |
Apr
(99) |
May
(123) |
Jun
(69) |
Jul
(110) |
Aug
(130) |
Sep
(289) |
Oct
(211) |
Nov
(98) |
Dec
(140) |
2004 |
Jan
(85) |
Feb
(87) |
Mar
(342) |
Apr
(125) |
May
(101) |
Jun
(60) |
Jul
(151) |
Aug
(118) |
Sep
(162) |
Oct
(117) |
Nov
(125) |
Dec
(95) |
2005 |
Jan
(141) |
Feb
(54) |
Mar
(79) |
Apr
(83) |
May
(74) |
Jun
(125) |
Jul
(63) |
Aug
(89) |
Sep
(130) |
Oct
(89) |
Nov
(34) |
Dec
(39) |
2006 |
Jan
(98) |
Feb
(62) |
Mar
(56) |
Apr
(94) |
May
(169) |
Jun
(41) |
Jul
(34) |
Aug
(35) |
Sep
(132) |
Oct
(722) |
Nov
(381) |
Dec
(36) |
2007 |
Jan
(34) |
Feb
(174) |
Mar
(15) |
Apr
(35) |
May
(74) |
Jun
(15) |
Jul
(8) |
Aug
(18) |
Sep
(39) |
Oct
(125) |
Nov
(89) |
Dec
(129) |
2008 |
Jan
(176) |
Feb
(91) |
Mar
(69) |
Apr
(178) |
May
(310) |
Jun
(434) |
Jul
(171) |
Aug
(73) |
Sep
(187) |
Oct
(132) |
Nov
(259) |
Dec
(292) |
2009 |
Jan
(27) |
Feb
(54) |
Mar
(35) |
Apr
(54) |
May
(93) |
Jun
(10) |
Jul
(36) |
Aug
(36) |
Sep
(93) |
Oct
(52) |
Nov
(45) |
Dec
(74) |
2010 |
Jan
(20) |
Feb
(120) |
Mar
(165) |
Apr
(101) |
May
(56) |
Jun
(12) |
Jul
(73) |
Aug
(306) |
Sep
(154) |
Oct
(82) |
Nov
(63) |
Dec
(42) |
2011 |
Jan
(176) |
Feb
(86) |
Mar
(199) |
Apr
(86) |
May
(237) |
Jun
(50) |
Jul
(26) |
Aug
(56) |
Sep
(42) |
Oct
(62) |
Nov
(62) |
Dec
(52) |
2012 |
Jan
(35) |
Feb
(33) |
Mar
(128) |
Apr
(152) |
May
(133) |
Jun
(21) |
Jul
(74) |
Aug
(423) |
Sep
(165) |
Oct
(129) |
Nov
(387) |
Dec
(276) |
2013 |
Jan
(105) |
Feb
(30) |
Mar
(130) |
Apr
(42) |
May
(60) |
Jun
(79) |
Jul
(101) |
Aug
(46) |
Sep
(81) |
Oct
(14) |
Nov
(43) |
Dec
(4) |
2014 |
Jan
(25) |
Feb
(32) |
Mar
(30) |
Apr
(80) |
May
(42) |
Jun
(23) |
Jul
(68) |
Aug
(127) |
Sep
(112) |
Oct
(72) |
Nov
(29) |
Dec
(69) |
2015 |
Jan
(35) |
Feb
(49) |
Mar
(95) |
Apr
(10) |
May
(70) |
Jun
(64) |
Jul
(93) |
Aug
(85) |
Sep
(43) |
Oct
(38) |
Nov
(124) |
Dec
(29) |
2016 |
Jan
(253) |
Feb
(181) |
Mar
(132) |
Apr
(419) |
May
(68) |
Jun
(90) |
Jul
(52) |
Aug
(142) |
Sep
(131) |
Oct
(80) |
Nov
(84) |
Dec
(192) |
2017 |
Jan
(329) |
Feb
(842) |
Mar
(248) |
Apr
(85) |
May
(247) |
Jun
(186) |
Jul
(37) |
Aug
(73) |
Sep
(98) |
Oct
(108) |
Nov
(143) |
Dec
(143) |
2018 |
Jan
(155) |
Feb
(139) |
Mar
(72) |
Apr
(112) |
May
(82) |
Jun
(119) |
Jul
(24) |
Aug
(33) |
Sep
(179) |
Oct
(295) |
Nov
(111) |
Dec
(34) |
2019 |
Jan
(20) |
Feb
(29) |
Mar
(49) |
Apr
(89) |
May
(185) |
Jun
(131) |
Jul
(9) |
Aug
(59) |
Sep
(30) |
Oct
(44) |
Nov
(118) |
Dec
(53) |
2020 |
Jan
(70) |
Feb
(108) |
Mar
(50) |
Apr
(9) |
May
(70) |
Jun
(24) |
Jul
(103) |
Aug
(82) |
Sep
(132) |
Oct
(119) |
Nov
(174) |
Dec
(169) |
2021 |
Jan
(75) |
Feb
(51) |
Mar
(76) |
Apr
(73) |
May
(53) |
Jun
(120) |
Jul
(114) |
Aug
(73) |
Sep
(70) |
Oct
(18) |
Nov
(26) |
Dec
|
2022 |
Jan
(26) |
Feb
(63) |
Mar
(64) |
Apr
(64) |
May
(48) |
Jun
(74) |
Jul
(129) |
Aug
(106) |
Sep
(238) |
Oct
(169) |
Nov
(149) |
Dec
(111) |
2023 |
Jan
(110) |
Feb
(47) |
Mar
(82) |
Apr
(106) |
May
(168) |
Jun
(101) |
Jul
(155) |
Aug
(35) |
Sep
(51) |
Oct
(55) |
Nov
(134) |
Dec
(202) |
2024 |
Jan
(103) |
Feb
(129) |
Mar
(154) |
Apr
(75) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Neil M. <nem@Cs.Nott.AC.UK> - 2008-06-22 06:42:17
|
On 21 Jun 2008, at 22:23, Frédéric Bonnet wrote: > [...] > But back to the OT. Since everybody seems to ask for a use case to > justify the need for a null in Tcl, I'll give one below, but first > let's > all remember what Tcl means: Tool Command Language. Tcl was born as a > generic scripting language to control existing software written in > lower > level languages. It then evolved into our favorite multi-paradigm > language, which allows users to write software in any way they choose: > procedural, OO, functional, RAD, quick & dirty, you name it. But above > all, the choice is up to the user (heck, we even have *several* OO > solutions to choose from). Tcl has never been an exercise in language > theory, but a tool to get the job done in the least intrusive way. > Above > all, Tcl is and remains a *glue* language to connect pieces of > software > written in different languages, using different styles and different > models. Tcl's philosophy is not "don't do it because it's bad", but > "if > you don't like it, don't use it". I look forward to raw pointer access to memory, unsynchronized shared-state threads, and gotos. > > Now for the use case. Let's use Tcl the way it was designed for: as a > glue language for writing interface layers to system-level code. > > I want to write a Tcl interface layer to an existing library > written in > C. To minimize the learning curve and the documentation effort, I want > the Tcl API to match the C API as closely as possible. If minimising effort and closely matching the C API is the goal, then why not just use Swig? Here's how swig handles NULLs [http:// www.swig.org/Doc1.1/HTML/SWIG.html#n3]: "A NULL pointer is represented by the string "NULL" or the value 0 encoded with type information." Seems to work just fine. No magic, no fuss. A simple string. > This means > mapping C procs to Tcl commands with the same argument list. I also > define a C struct <-> Tcl string mapping that makes sense and > allows the > use of standard Tcl commands whenever possible (e.g. C structs are > mapped to Tcl lists or dicts). But this specific library makes use of > NULL values in several places and in various situations. Sometimes > there > is a matching Tcl feature, like optional args, but sometimes there > isn't. As I want to keep as close to the original API as possible, I > can't use wrapping techniques such as Haskell's Maybe, so I choose to > use direct values everywhere. Firstly -- if you are using dicts as structs, then where is the problem? I also don't understand why maybe is discounted despite there being an exact 1-to-1 mapping between it and a C pointer type, as I've previously pointed out. Just rename the constructors if you want to be closer to C: proc & val { Just $val } proc NULL {} { Nothing } I mean, if you are trying to keep close to C then presumably you are defining *some* sort of mapping for pointer/reference types, otherwise how do you handle mutations? E.g. in C code like: struct foo { int refCount; ... }; void AddRef(struct foo *fooPtr) { fooPtr->refCount++; } Clearly you couldn't map that into a Tcl command that just takes a dict/list Tcl_Obj and then mutates it, as it will blow up if the Tcl_Obj is shared. > This means that whenever I need NULL to be > an accepted value, I have the same problem: either there are "free" > values in the domain, or there aren't. In the former case, in order to > remain overly consistent, I have to choose the same value > everywhere so > as to minimize the learning curve. In the latter case, I'm toast, > so I'm > forced to resort to painful contortions that break the overall > consistency of my interface layer. I'm sure there are plenty of places where a special NULL marker *seems* like a good idea. My experience is that in all of these cases, NULL just adds more problems without actually making anything any easier. As I said way, way, way back at the start of this thread (4th June): "This is not a good solution, either theoretically *or practically*." (emphasis added). The argument has never been some theory vs practice or academia vs The Real World (TM). It's about what is a good solution *in practice*. Theory just informs that debate and provides a structure for evaluating alternatives. -- Neil This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. |
From: miguel s. <mig...@gm...> - 2008-06-22 06:28:11
|
Larry McVoy wrote: > On Sat, Jun 21, 2008 at 11:11:06PM +1000, Colin McCormack wrote: > [...] >> When Neil Madden said (on 11/06/08 19:19) >> >>> I know for sure that the programming language researchers here at >>>> Nottingham would laugh you out of the room if you suggested designing >>>> a programming language with "null" in 2008. >>> >> You replied: "Goody for them. I used to be in awe of university types >> until I moved into industry and did actual work that real users used." >> >> "Actual work, that real users use." One infers that L is intended to be >> an example of this actual work. Except that apparently it actually >> doesn't work as currently implemented, in that you seem to feel that an >> L struct needs to be able to contain undefined elements, and as >> currently implemented it can't. >> >> I think there's a hint to your actual problem right here: >> >> LMcVoy "11/06/08 14:11" >> >> | I've talked this over with a bunch of other >> | language people and they all think that it's insane that I even have to >> | argue this point. I'm doing it to try and fit in here but you need to >> | know that the rest of the languages people would be rolling on the floor >> | laughing at this. Come on. Larry: given that you never fail to mention your large investment in Tcl, the availability of funding for further improvements and your access to bunches of language people ... maybe there exists a possibility that you get them to contribute a solution together with a clear statement of the problem? You know what I mean: an actual industrial solution that actually works and real users could actually use (aka code). Please refer them to the FR facility at sourceforge, and also to http://tip.tcl.tk |
From: miguel s. <mig...@gm...> - 2008-06-22 06:14:02
|
Larry McVoy wrote: >> why you bought a bill of goods in 'tcl list == L struct' > > Perhaps you'd like the explain the inherent problems with tcl lists that > make them not suitable as a container for a list of values? They are perfectly suitable as a container for a list of values; they cannot accomodate non-values. This whole discussion is an "exploration" of: can we extend the universe of values to contain a non-value too [*]? In that way, the tcl list could handle other use cases. A different solution, of course, is: use a different container when you also want undefs in there. Tcl has dicts for that purpose. ---- [*] I know, it even *sounds* weird |
From: miguel s. <mig...@gm...> - 2008-06-22 06:03:09
|
Colin McCormack wrote: > Larry McVoy wrote: >> Nobody, in all of their use cases, have asked for a way to serialize >> NULL to disk. Yet all of the discussion has been "we can't send >> NULL to disk so therefor NULL is bad". Hey, tcl folks, when did I, >> the guy who started this mess, ever ask you to make it work going >> to disk? Never happened. So why fixate on that? Hmm? >> > > Well, it may be that the general consensus is that being able to send an > arbitrary value to disk, and reconstruct it from that disk form, is more > useful than the ability to use tcl data structures to implement L data > structures. > > Ever think of that? To disk ... or to a different interpreter, maybe running in another thread or even another machine. |
From: <lm...@bi...> - 2008-06-22 05:28:13
|
On Sat, Jun 21, 2008 at 11:11:06PM +1000, Colin McCormack wrote: [lots of stuff that said (a) I'm stealing tcl for L and (b) show a use case for null.] Let's deal with the L stuff first. L uses tcl data structures to implement L data structures. So if L has a problem, tcl has a problem. There isn't any difference. Nice try, Colin but no dice. Use cases: the SQL query is an example that keeps coming back (nothing to do with L there, is there, Colin?). Either Donal or Kevin brought up sparse matrices. If you have to build a 2d or 3d matrix and 90% of it is empty and it is big, wouldn't it be nice to have a NULL you could stick in there? Signs point to yes. Finally, EIAS. This isn't just Colin, this is piles of people. Christ on a stick, people, get a grip. It's not like EIAS is the one true path to enlightenment. In fact, it seems like that mantra, over and over again, causes TCL problems. Cleaving to it is good why? Did John have this EIAS mantra? I suspect not. And I suspect he'd say get over your fine selves and make the language useful. Nobody, in all of their use cases, have asked for a way to serialize NULL to disk. Yet all of the discussion has been "we can't send NULL to disk so therefor NULL is bad". Hey, tcl folks, when did I, the guy who started this mess, ever ask you to make it work going to disk? Never happened. So why fixate on that? Hmm? --lm > >>Of course, it's not that you're trying to make tcl better. > >> > > > >If this were true, or were held to be true, so be it. > > > >But for better or worse, I'm trying to make tcl be better. > > Could you, then, provide a use case in tcl which would demonstrate your > desire to improve tcl with NULL, and where NULL would be worth its > considerable cost? > > >It may be that > >I'm so wrong that I'm making it worse. As soon as someone can show me > >that that is what I'm doing I'll shut up. > > There is ample evidence that you are attempting to push something tcl > can't use, doesn't need, isn't really compatible with. Do you require a > summary of that evidence and argument, or are you merely feigning ignorance? > > >So far, you're not doing a good job if that is your goal. > > > > Yeah. I don't really think any form of words would suffice to convince > you, because I don't think you're actually interested in tcl, but only > in using tcl core for L. > > The only use case you've given for NULL is as follows: > > 11/06/08 08:15 LMcVoy: > > | we're implementing complex data structures in L, > | which compiles to tcl byte codes. The data structures are C like and > | include arrays (multi dimensional), structs, and (not so C like) > | associative arrays (aka hashes). > | Arrays are implemented as tcl lists. Hashes are tcl dicts. Structs are > also lists. > | [...] > | Suppose you want to know if v[1].h is defined? Or any of the other > subfields. > | Gets messy. A NULL obj would make this a lot easier. > > That's not a tcl use case, it's an L use case. There is no reason to > suppose that NULL makes anything in tcl easier, and ample evidence and > argument to the contrary. I would say overwhelming evidence and argument > to the contrary from people in a position to know. > > On this basis, it would be fair and reasonable to say that you have no use > case for tcl. It would be reasonable to suppose that your entire interest > in the topic is this problem you have discovered in your implementation of > L structs as lists. > > I have also heard a fair bit about your vast and wide experience in > languages. > > When Neil Madden said (on 11/06/08 19:19) > > >I know for sure that the programming language researchers here at > >> Nottingham would laugh you out of the room if you suggested designing > >> a programming language with "null" in 2008. > > > You replied: "Goody for them. I used to be in awe of university types > until I moved into industry and did actual work that real users used." > > "Actual work, that real users use." One infers that L is intended to be > an example of this actual work. Except that apparently it actually > doesn't work as currently implemented, in that you seem to feel that an > L struct needs to be able to contain undefined elements, and as > currently implemented it can't. > > I think there's a hint to your actual problem right here: > > LMcVoy "11/06/08 14:11" > > | I've talked this over with a bunch of other > | language people and they all think that it's insane that I even have to > | argue this point. I'm doing it to try and fit in here but you need to > | know that the rest of the languages people would be rolling on the floor > | laughing at this. Come on. > > Larry, I'm guessing these 'other language people' failed to mention to > you that your use of tcl list as the basis of your L structs would have > the property of being unable to detect absence. Yet these are the > "language people" upon whom you rely, and whom you hold up as > authorities in this discussion? Are they in-house "language people" who > painted you into this corner, or are they ambient and anonymous > "language people" who are too busy ROFLing to give you the advice you'd > have needed to avoid your cul de sac? > > I don't suppose it needs to be said, but these "language people" aren't > from universities, are they. They're from that space where "actual work, > that real users use" is done. So, can one of them, can any of them, find > a single *tcl* use case for NULL which hasn't been argued to death here? > > Otherwise, I think it's time you accepted the consensus of real experts > in the language who have told you that NULL is ill advised, or perhaps > to decide to take the advice of your language experts, and find a host > language implementation more suited to your needs. I hear parrot's nice. > Perhaps a species of JVM ... Sun might even offer to fund you. I bet > both of them have NULL, too. > > Colin. -- --- Larry McVoy lm at bitmover.com http://www.bitkeeper.com |
From: <lm...@bi...> - 2008-06-22 05:28:12
|
> why you bought a bill of goods in 'tcl list == L struct' Perhaps you'd like the explain the inherent problems with tcl lists that make them not suitable as a container for a list of values? -- --- Larry McVoy lm at bitmover.com http://www.bitkeeper.com |
From: <lm...@bi...> - 2008-06-22 05:28:12
|
On Sun, Jun 22, 2008 at 12:02:22PM +1000, Colin McCormack wrote: > Larry McVoy wrote: > >I'll take the advice of many and not rise to the bait. > > FWIW, if these advisors are the same people who advised you to use tcl > lists to implement containers which may have holes, then it seems to me > you are persistently ill-advised, and you ought to consider > re-evaluating more than your implementation decisions, perhaps focusing > more on your implementation decision making process. You are so right, Colin. Perhaps you'd like to apply for the job? Be a fun interview... > >The fact that > >the issue has legs and keeps coming back means that it is bigger than > >me and I don't matter. Love that. Go NULLs! > > What has legs, keeps coming back, and is bigger than Larry McVoy? I > dunno, a homesick waterbuffalo? A giant cockroach? Hmm. So the argument has gotten to "a homesick waterbuffalo". Interesting new level of technical discussion. I know you think that the advice is ill-founded, Colin, but when I'm supposed to argue with "a homesick waterbuffalo" theory of language design, I'll pass. -- --- Larry McVoy lm at bitmover.com http://www.bitkeeper.com |
From: Joe E. <jen...@fl...> - 2008-06-22 05:21:59
|
Jan Nijtmans wrote: > I'm just trying to be practical. How to satisfy people with what they > need, This is a noble and worthy goal. But it's important to distinguish what people need from what they *think* they need. > even though it is against EIAS? Discussing pro's and contra's > doesn't help any more, all arguments are already there wide out on > the table. The fact that something is theoretically wrong is not the > only thing important here. Cancelling a thread is not a good idea > either, but sometimes it is better than the alternative: a crash > because other people write bad code. Here is the same danger > that other people create bad extensions (or just trying to wrap > bad third-party code which dares to use NULL's). Couldn't we > provide a "string is null" command with a big warning USE > THIS ONLY AT YOUR OWN RISK, letting it be the only > command that violates EIAS. I could live with that. Maybe I'm wrong here, but it seems to me that instead of adding a feature and putting a big warning on it saying "DO NOT USE THIS FEATURE", it would be better to just not add the feature in the first place. It also seems to me that NULL values (a value that isn't a value? WTF?) are firmly in the category of "things that we do not want". Just because Perl and SQL have something doesn't mean Tcl should too. -JE |
From: Colin M. <co...@ch...> - 2008-06-22 05:12:05
|
Larry McVoy wrote: > On Sun, Jun 22, 2008 at 12:02:22PM +1000, Colin McCormack wrote: > >> Larry McVoy wrote: >> >>> I'll take the advice of many and not rise to the bait. >>> >> FWIW, if these advisors are the same people who advised you to use tcl >> lists to implement containers which may have holes, then it seems to me >> you are persistently ill-advised, and you ought to consider >> re-evaluating more than your implementation decisions, perhaps focusing >> more on your implementation decision making process. >> > > You are so right, Colin. Perhaps you'd like to apply for the job? Be > a fun interview... > Doubt you could afford me. I already own a notebook. >>> The fact that >>> the issue has legs and keeps coming back means that it is bigger than >>> me and I don't matter. Love that. Go NULLs! >>> >> What has legs, keeps coming back, and is bigger than Larry McVoy? I >> dunno, a homesick waterbuffalo? A giant cockroach? >> > > Hmm. So the argument has gotten to "a homesick waterbuffalo". Interesting > new level of technical discussion. This hasn't been a technical discussion for a while. This became a social/political discussion when you departed from the technical merits of your approach and began to speak in terms of mantras, meanings of life, personalities, historic missions, and so forth. Try to keep up. You think it's an 'issue,' I think it's a non-issue. I think it's more akin to a wallowing waterbuffalo. I've thought of something else that has legs, keeps coming back, and is bigger than L.McVoy: L.McVoy and an invisible army of laughing language people. > I know you think that the advice is ill-founded, Colin, but when I'm supposed > to argue with "a homesick waterbuffalo" theory of language design, I'll pass. > You really can't tell the difference between a technical discussion and a wallowing waterbuffalo. That explains a lot. Explains, for example,. why you bought a bill of goods in 'tcl list == L struct' Colin. |
From: <lm...@bi...> - 2008-06-22 05:11:33
|
I'll take the advice of many and not rise to the bait. The fact that the issue has legs and keeps coming back means that it is bigger than me and I don't matter. Love that. Go NULLs! -- --- Larry McVoy lm at bitmover.com http://www.bitkeeper.com |
From: Colin M. <co...@ch...> - 2008-06-22 02:39:38
|
Frédéric Bonnet wrote: > Now for the use case. [...] > > [it's a tcl interface to C.] > This means > mapping C procs to Tcl commands with the same argument list. Why? I dunno. But we'll let this one ride. > I also > define a C struct <-> Tcl string mapping that makes sense and allows the > use of standard Tcl commands whenever possible (e.g. C structs are > mapped to Tcl lists or dicts). If it's a struct -> tcl mapping, then it should use dict, if you intend to preserve C-NULLs. > But this specific library makes use of > NULL values in several places and in various situations. So the 'use case' is a C library which makes use of NULL values 'in several places' and in 'various situations' ... huh? I don't think this is really a use case, so much as a general description of the problem domain, but anyway, on we go. > Sometimes there > is a matching Tcl feature, like optional args, but sometimes there > isn't. C doesn't have 'optional args' as such, except an equivalent to tcl 'args' arg, and then via a library. This seems to contradict the stated desire to make arglists identical by name (above.) > As I want to keep as close to the original API as possible, I > can't use wrapping techniques such as Haskell's Maybe, so I choose to > use direct values everywhere. I'm assuming that your C program doesn't use utf8 encoding of strings, yet tcl does, because tcl must. That transformation (from ASCII to UTF) is acceptable to you. Why isn't a NULL-preserving encoding also acceptable? Why, therefore, can't you use wrapping techniques, as they are only encodings? > This means that whenever I need NULL to be > an accepted value, I have the same problem: either there are "free" > values in the domain, or there aren't. Or you pick an encoding which works - Haskell Maybe maybe the best encoding. > In the former case, in order to > remain overly consistent, I have to choose the same value everywhere so > as to minimize the learning curve. That's kinda the nature of encoding, you should choose the same value everywhere you want to represent the same sememe. > In the latter case, I'm toast, so I'm > forced to resort to painful contortions that break the overall > consistency of my interface layer. > Again, tcl uses UTF for strings, C uses ASCII. If you can cope with that transcoding, why can't you cope with a transcoding of possibly-NULL values, so that (for example) each presented non-null value in a possibly-null domain is wrapped as a list? It's just an encoding. Why are these 'painful contortions'? Why is it more 'painful' than the string encoding? How does a consistent encoding break anything? Is the pain really just a consequence of the necessity that you (the interfacer) have to choose and effect an encoding (one of several homologous encodings available), where the UTF encoding is done for you? The hypothetical situation you have chosen is contorted. You have maximally constrained consideration to exclude all useful applicable techniques other than the one you have chosen, and you have supposed that these constraints are reasonable without further consideration. I don't think the constraints are reasonable. Even if your hypothetical case occurred daily for every user of tcl, that they had to wrap or encode or otherwise deal with NULL values passed across C interfaces every single day, it still wouldn't *necessarily* justify the development expense of auditing each command in tcl to cope with an augmented value domain, nor would it necessarily justify the computational expense of implementing that augmentation by the additional requirement of *testing* each time a value is utilised, to compare it to the hypothetical solution NULL. It may well be that the inconvenience you postulate in this contrived example is justified by greater convenience elsewhere. Colin. |
From: Colin M. <co...@ch...> - 2008-06-22 02:20:14
|
Larry McVoy wrote: > I'll take the advice of many and not rise to the bait. FWIW, if these advisors are the same people who advised you to use tcl lists to implement containers which may have holes, then it seems to me you are persistently ill-advised, and you ought to consider re-evaluating more than your implementation decisions, perhaps focusing more on your implementation decision making process. But that's just my opinion. > The fact that > the issue has legs and keeps coming back means that it is bigger than > me and I don't matter. Love that. Go NULLs! > What has legs, keeps coming back, and is bigger than Larry McVoy? I dunno, a homesick waterbuffalo? A giant cockroach? Much as I love nature programs and SF with giant animals, and much as I love *anything* which convinces LMcVoy that he doesn't matter ... this whole thing is an attempted hijacking of tcl mindshare to protect LM from realising that he's made a technical error, and growing balls (and finding sufficiently adept language advisors) enough to address the problem. Colin. |
From: Colin M. <co...@ch...> - 2008-06-22 01:59:53
|
Larry McVoy wrote: > On Sat, Jun 21, 2008 at 11:11:06PM +1000, Colin McCormack wrote: > [lots of stuff that said (a) I'm stealing tcl for L and (b) show a > use case for null.] > Nobody said 'steal tcl'. How is that even possible? You're probably stealing attention for L's problems, they are of your own making, you shouldn't do it. > Let's deal with the L stuff first. L uses tcl data structures to > implement L data structures. So if L has a problem, tcl has a > problem. There isn't any difference. Nice try, Colin but no dice. > This is of course fallacious reasoning. Tcl doesn't use tcl data structures to implement L data structures, so if L has a problem using tcl data structures to implement non-tcl data structures, and does so badly, it has of course absolutely no impact on tcl. So, to be pellucidly clear on this: You made an error of judgement if you require L data structures to represent NULL, and you chose to use the tcl list structure. The solution is not to rewrite the tcl list structure, it's to properly reconsider what data structure you ought to be using. > Use cases: the SQL query is an example that keeps coming back (nothing > to do with L there, is there, Colin?). No, and it's been dealt with. Hell, I have to deal with it myself ... regularly. And I do so by using the appropriate tcl data struc tures, which also don't generalise to L's misuse of tcl data structures. > Either Donal or Kevin brought up sparse matrices. If you have to build > a 2d or 3d matrix and 90% of it is empty and it is big, wouldn't it be > nice to have a NULL you could stick in there? Signs point to yes. > I know what a 'sparse matrix' is. Most matrices are numeric. The empty string value serves well as a place holder in that case. Depending upon how sparse and large the matrix in question is, it may even make sense to store it as a hash table. This isn't a compelling case for NULL. > Finally, EIAS. This isn't just Colin, this is piles of people. > What does that even mean? Is this just another personalised red-herring thrown up in lieue of decent or compelling arguments? > Christ on a stick, people, get a grip. It's not like EIAS is the > one true path to enlightenment. I don't recall anybody ever saying it was the one true path to enlightenment I believe it's a useful property of tcl as a language, more useful than a similar language to tcl, but augmented with NULL, would be. > In fact, it seems like that mantra, > over and over again, causes TCL problems. Cleaving to it is good > why? Did John have this EIAS mantra? I suspect not. And I suspect > he'd say get over your fine selves and make the language useful. > This is a strawman argument. Clearly, tcl is useful. > Nobody, in all of their use cases, have asked for a way to serialize > NULL to disk. Yet all of the discussion has been "we can't send > NULL to disk so therefor NULL is bad". Hey, tcl folks, when did I, > the guy who started this mess, ever ask you to make it work going > to disk? Never happened. So why fixate on that? Hmm? > Well, it may be that the general consensus is that being able to send an arbitrary value to disk, and reconstruct it from that disk form, is more useful than the ability to use tcl data structures to implement L data structures. Ever think of that? Colin. |
From: Donald A. <as...@tr...> - 2008-06-22 00:36:51
|
"Jan Nijtmans" <nij...@us...> writes: > So I have been experimenting a little bit with an alternative. What if we > had a null value which is easy to check for, and which string representation > is the empty string? Then we keep the EIAS principle. Either the null value is an empty string, in which case it is not very useful because empty strings crop up all over, or it is not an empty string, in which case "string representation is the empty string" is a bug. -- Donald Arseneau as...@tr... |
From: Frédéric B. <fre...@fr...> - 2008-06-21 23:40:26
|
Fredderic Unpenstein wrote: > On 21/06/2008, Frédéric Bonnet <fre...@fr...> wrote: > Theoretical objections... Reminds me of several people just recently, > one particularly good example very recently. "Oh, but they did such a > good job of thinking for me!" It's a mentality that really gets me > riled up. TCL, last time I checked, stands for Tool Command Language, > not Tools Controlled Language. Tools Controlled Language, hehehe. Regarding theory vs. practice, here is a nice quote: "Theory may inform, but practice convinces" - George Bain I used this as a .sig for several years. Here's another, more humorous saying: "In theory, there is no difference between theory and practice. But, in practice, there is". Thank you, I'm here all week. But back to the OT. Since everybody seems to ask for a use case to justify the need for a null in Tcl, I'll give one below, but first let's all remember what Tcl means: Tool Command Language. Tcl was born as a generic scripting language to control existing software written in lower level languages. It then evolved into our favorite multi-paradigm language, which allows users to write software in any way they choose: procedural, OO, functional, RAD, quick & dirty, you name it. But above all, the choice is up to the user (heck, we even have *several* OO solutions to choose from). Tcl has never been an exercise in language theory, but a tool to get the job done in the least intrusive way. Above all, Tcl is and remains a *glue* language to connect pieces of software written in different languages, using different styles and different models. Tcl's philosophy is not "don't do it because it's bad", but "if you don't like it, don't use it". Now for the use case. Let's use Tcl the way it was designed for: as a glue language for writing interface layers to system-level code. |
From: Frédéric B. <fre...@fr...> - 2008-06-21 21:44:23
|
Ah, fuck, I hit the send button by accident, sorry about that. Fredderic Unpenstein wrote: > Theoretical objections... Reminds me of several people just recently, > one particularly good example very recently. "Oh, but they did such a > good job of thinking for me!" It's a mentality that really gets me > riled up. TCL, last time I checked, stands for Tool Command Language, > not Tools Controlled Language. Tools Controlled Language, hehehe. Regarding theory vs. practice, here is a nice quote: "Theory may inform, but practice convinces" - George Bain I used this as a .sig for several years. Here's another, more humorous saying: "In theory, there is no difference between theory and practice. But, in practice, there is". Thank you, I'm here all week. But back to the OT. Since everybody seems to ask for a use case to justify the need for a null in Tcl, I'll give one below, but first let's all remember what Tcl means: Tool Command Language. Tcl was born as a generic scripting language to control existing software written in lower level languages. It then evolved into our favorite multi-paradigm language, which allows users to write software in any way they choose: procedural, OO, functional, RAD, quick & dirty, you name it. But above all, the choice is up to the user (heck, we even have *several* OO solutions to choose from). Tcl has never been an exercise in language theory, but a tool to get the job done in the least intrusive way. Above all, Tcl is and remains a *glue* language to connect pieces of software written in different languages, using different styles and different models. Tcl's philosophy is not "don't do it because it's bad", but "if you don't like it, don't use it". Now for the use case. Let's use Tcl the way it was designed for: as a glue language for writing interface layers to system-level code. I want to write a Tcl interface layer to an existing library written in C. To minimize the learning curve and the documentation effort, I want the Tcl API to match the C API as closely as possible. This means mapping C procs to Tcl commands with the same argument list. I also define a C struct <-> Tcl string mapping that makes sense and allows the use of standard Tcl commands whenever possible (e.g. C structs are mapped to Tcl lists or dicts). But this specific library makes use of NULL values in several places and in various situations. Sometimes there is a matching Tcl feature, like optional args, but sometimes there isn't. As I want to keep as close to the original API as possible, I can't use wrapping techniques such as Haskell's Maybe, so I choose to use direct values everywhere. This means that whenever I need NULL to be an accepted value, I have the same problem: either there are "free" values in the domain, or there aren't. In the former case, in order to remain overly consistent, I have to choose the same value everywhere so as to minimize the learning curve. In the latter case, I'm toast, so I'm forced to resort to painful contortions that break the overall consistency of my interface layer. |
From: Daniel A. S. <st...@ma...> - 2008-06-21 16:44:51
|
On 21/06/2008, at 15:33, Daniel A. Steffen wrote: > Given that this exact scheme has been working fine for a long time > for 0xc080 I don't think there should be any core > code changes needed outside of UtfToUtfProc() (note that round- > tripping through ucs-2 will work fine c.f. Tcl_UtfToUniChar()). oops, I withdraw that last comment, Tcl_UtfToUniChar() would also need to be adapted (or a sequence like 0xc0c0 chosen for the null string rep, which Tcl_UtfToUniChar() transforms to \u0000). Cheers, Daniel -- ** Daniel A. Steffen ** ** <mailto:da...@us...> ** |
From: Daniel A. S. <da...@us...> - 2008-06-21 16:15:38
|
Kind of reluctant to enter this discussion, probably a mistake to do so ;), but here goes anyway: On 19/06/2008, at 12:48, Donal K. Fellows wrote: > Fredderic Unpenstein wrote: >> Just to put this idea to rest, how do you find a value that won't >> clash, while writing a utility function that has little or no idea of >> exactly what values it will be working with, or gets handed arbitrary >> (potentially binary) data...? > > Some of the Unicode characters outside \u0000-\u00ff are genuinely > unlikely to come up by mistake. there are actually character sequences that that we _know_ will never come up in a string representation because they are ill-formed utf-8. We are already using such a sequence (0xc080) to represent \u0000 (c.f. UtfToUtfProc) in string reps, there are many more such sequences that could be used for the string rep of a null Tcl_Obj, e.g. 0xc081, 0xc180 etc. BTW, the same is true for utf-16 (if we ever manage to migrate to that from UCS-2...) e.g. the sequence 0xd8111111 is ill-formed utf-16 (an isolated high surrogate) and will never be produced by (correct) conversion to utf-16. This works because in the implementation, EIAS is actually EIAUTF8S (everything is a utf-8 string) which is very different from the free monoid of all strings mentioned earlier (yay, category theory! ;), the space of valid utf-8 sequences is far from dense (see e.g. Table 3-7 in the Unicode Standard 5.0) and leaves us with numerous sequences that are outside of the domain of valid string representations. Concretely, a null Tcl_Obj would on creation be like the current empty object, except that its string rep would be say 0xc081 instead of tclEmptyStringRep. UtfToUtfProc() would need to be modified to translate that sequence on output e.g. to \ufffd (the unicode replacement character for unknown or not-representable values). Nothing would be done on input since 0xc081 can never be produced as valid utf-8. With this scheme nullness would only be lost at encoding boundaries (which the null proponents could hopefully live with), but beyond that EIAS would not be affected, the null Tcl_Obj would have a unique string representation distinct from all others, and would survive all tcl operations such as string concatenation etc that do not involve encoding conversion. Given that this exact scheme has been working fine for a long time for 0xc080 I don't think there should be any core code changes needed outside of UtfToUtfProc() (note that round- tripping through ucs-2 will work fine c.f. Tcl_UtfToUniChar()). Of course such a scheme still breaks EIAUTF8S, passage through the encoding system will be lossy (but note that that can actually already be the case now, e.g. incorrectly formed utf-8 is changed on input by UtfToUtfProc(), and non-unicode encodings are obviously even more lossy). In particular it will not possible to manually generate the string rep of the null Tcl_Obj from a string via escape sequences etc except by using/transforming the string rep of the null Tcl_Obj itself, but that should be considered a feature ;) I may be overlooking something, but at first glance, this seems like a very mild form of EIAS breakage that should not affect any null- unaware tcl or C code (anything that passes through the current 0xc080 scheme for \u0000 will work with this) but would still allow creation of null Tcl_Objs and [isnull] testing as proposed by Larry. Obviously this is a compromise solution because such a null Tcl_Obj does not have all the properties people may want from a null (it is a string of length 1 after all), e.g. you can concatenate such nulls into a string of multiple nulls, and you have {$null eq $null}, {[string length $null] == 1} and so on... Cheers, Daniel -- ** Daniel A. Steffen ** ** <mailto:da...@us...> ** |
From: Colin M. <co...@ch...> - 2008-06-21 13:11:07
|
Larry McVoy wrote: >> Of course, it's not that you're trying to make tcl better. >> > > If this were true, or were held to be true, so be it. > > But for better or worse, I'm trying to make tcl be better. Could you, then, provide a use case in tcl which would demonstrate your desire to improve tcl with NULL, and where NULL would be worth its considerable cost? > It may be that > I'm so wrong that I'm making it worse. As soon as someone can show me > that that is what I'm doing I'll shut up. There is ample evidence that you are attempting to push something tcl can't use, doesn't need, isn't really compatible with. Do you require a summary of that evidence and argument, or are you merely feigning ignorance? > So far, you're not doing a good job if that is your goal. > Yeah. I don't really think any form of words would suffice to convince you, because I don't think you're actually interested in tcl, but only in using tcl core for L. The only use case you've given for NULL is as follows: 11/06/08 08:15 LMcVoy: | we're implementing complex data structures in L, | which compiles to tcl byte codes. The data structures are C like and | include arrays (multi dimensional), structs, and (not so C like) | associative arrays (aka hashes). | Arrays are implemented as tcl lists. Hashes are tcl dicts. Structs are also lists. | [...] | Suppose you want to know if v[1].h is defined? Or any of the other subfields. | Gets messy. A NULL obj would make this a lot easier. That's not a tcl use case, it's an L use case. There is no reason to suppose that NULL makes anything in tcl easier, and ample evidence and argument to the contrary. I would say overwhelming evidence and argument to the contrary from people in a position to know. On this basis, it would be fair and reasonable to say that you have no use case for tcl. It would be reasonable to suppose that your entire interest in the topic is this problem you have discovered in your implementation of L structs as lists. I have also heard a fair bit about your vast and wide experience in languages. When Neil Madden said (on 11/06/08 19:19) > I know for sure that the programming language researchers here at > > Nottingham would laugh you out of the room if you suggested designing > > a programming language with "null" in 2008. > You replied: "Goody for them. I used to be in awe of university types until I moved into industry and did actual work that real users used." "Actual work, that real users use." One infers that L is intended to be an example of this actual work. Except that apparently it actually doesn't work as currently implemented, in that you seem to feel that an L struct needs to be able to contain undefined elements, and as currently implemented it can't. I think there's a hint to your actual problem right here: LMcVoy "11/06/08 14:11" | I've talked this over with a bunch of other | language people and they all think that it's insane that I even have to | argue this point. I'm doing it to try and fit in here but you need to | know that the rest of the languages people would be rolling on the floor | laughing at this. Come on. Larry, I'm guessing these 'other language people' failed to mention to you that your use of tcl list as the basis of your L structs would have the property of being unable to detect absence. Yet these are the "language people" upon whom you rely, and whom you hold up as authorities in this discussion? Are they in-house "language people" who painted you into this corner, or are they ambient and anonymous "language people" who are too busy ROFLing to give you the advice you'd have needed to avoid your cul de sac? I don't suppose it needs to be said, but these "language people" aren't from universities, are they. They're from that space where "actual work, that real users use" is done. So, can one of them, can any of them, find a single *tcl* use case for NULL which hasn't been argued to death here? Otherwise, I think it's time you accepted the consensus of real experts in the language who have told you that NULL is ill advised, or perhaps to decide to take the advice of your language experts, and find a host language implementation more suited to your needs. I hear parrot's nice. Perhaps a species of JVM ... Sun might even offer to fund you. I bet both of them have NULL, too. Colin. |
From: Fredderic U. <mag...@gm...> - 2008-06-21 13:06:05
|
Never has there been a truer topic in here, for more reasons than this...! On 20/06/2008, Donal K. Fellows <don...@ma...> wrote: > The main problem with doing anything about this is that it changes the > nature of Tcl's value space. Right now, Tcl's values are taken from the > (infinite) set of all possible finite strings. (Well, modulo being > shorter than 2GB; I think we run into problems after that.) All other > Tcl_Obj types represent views on this underlying reality. The problem is > that NULL is a value that is distinct from all those other values; it > cannot be a string! Or at least not in any conventional sense. Given > that, it's a semantic change of a very profound nature and I'm unhappy > with doing anything about it in a minor version. Jolly well said, even if the implication sometimes sucks. On 20/06/2008, Jan Nijtmans <jan...@gm...> wrote: > 2008/6/20 Donal K. Fellows <don...@ma...>: >> By profound I mean that it affects the language definition massively, > That's what I thought initially as well. But the Tcl null object is NOT > equal to NULL in C. So extensions unaware of "string is null" or > Tcl_ObjIsNull are not affected (Honest!): They see null objects as > empty string. At C-level, NULL as any argument is still forbidden. > Backwards compatibility is crucial, especially in a minor version. Mine and several others arguments as already put a few times... NULL can be a regular Tcl_Obj. It's semantics can be quibbled over, but in this form, it shouldn't cause any significant change to TCL's core or extensions. They just go along using it as a regular value. Breaking EIAS for a NULL is something I'm undecided on. Especialy in the face of other alternatives which apply in the rather small subset of cases where it's actually safe. (The "actually safe" bit was the deciding factor for me, in hopping off the NULL bandwagon.) I think allowing NULLs to only be special in lists would be okay, if TCL didn't still hang off the string representation so tightly. There are still too many places where a subtle change of internal state causes the value to temporarily become a string, which would cause the magic NULLs to vanish mysteriously. Mind you, I think it could still be useful to have it being returned as a temporary result, with the awareness that it is to be tested immediately and disposed of (or consumed by your favourite method) as soon as possible. The we'll chuck an error if you don't idea has some merit here, but should it accidentally shimmer there'll be strange unexpected and unpredictable errors popping out. So I accept that it's an option that disturbs a lot of people for very good reasons. On 21/06/2008, Frédéric Bonnet <fre...@fr...> wrote: > miguel sofer wrote: >> Please do understand that I just want to establish that this proposal does >> break EIAS. It is *not* a "it breaks EIAS, blah blah can't hear you". It is >> rather "it breaks EIAS, let us research all implications of this, as it could be >> introducing subtle but fundamental issues that will bite us in the backside". > Glad to see some critical thinking here besides all the theoretical > objections so far (however valid they might be). Theoretical objections... Reminds me of several people just recently, one particularly good example very recently. "Oh, but they did such a good job of thinking for me!" It's a mentality that really gets me riled up. TCL, last time I checked, stands for Tool Command Language, not Tools Controlled Language. (And no, the unlikely character issue still doesn't count, IMHO, either for or against that comment. It has its uses in tightly confined contexts, but I've had to track down a problem where two pieces of code in a project from different people just happened to pick the same "unlikely character" - though more of an unlikely value in that case - and the results weren't pretty, and were a total PITA to track down. Similar issues also occur in totally different senarios as well. There've been security flaws found in critical software simply because someone picked an "unlikely character", and someone left a door open somewhere to slip one through.) Personally, I go out of my way to challenge set ideas (which does occasionally run me headlong into some well respected names with a whole lot of experience to squish me with), and I absolutely detest the whole "justify your idea" mentality, unless it involves a significant change (adding a command option where there isn't one, counts. Adding an extra field to a Tcl_Obj counts. Adding an extra field to a Tcl_ObjType counts very little). Doesn't always mean I actually want to see them changed, either... But yes, when your only reason to object is "but they don't do it that way", I can't help wondering if it's more an issue of just not wanting to "share the glory", such as it is in a collaborative work. Fredderic |
From: <lm...@bi...> - 2008-06-21 13:04:53
|
On Sat, Jun 21, 2008 at 01:22:56PM +1000, Colin McCormack wrote: > Larry McVoy wrote: > >>In all fairness, IIUC, this is (just about the same as) Larry's proposal. > >> > >>I guess I owe it to LM, here goes my comment in brief, so he can stop > >>reading right here: blah blah blah I can't hear you, EIAS, I can't hear > >>you! > >> > > > >+1 for humor. > > > > Here's my +1 for STFU. Hey, I'm OK with that. As soon as you move things forward better than I do. As soon as you contribute more effort than I do. As soon as you spend more money than I do. For tcl being better. I'll grant you that you are better than me at making tcl be the same. -- --- Larry McVoy lm at bitmover.com http://www.bitkeeper.com |
From: Frédéric B. <fre...@fr...> - 2008-06-21 12:50:41
|
Fredderic Unpenstein wrote: >> Some of the Unicode characters outside \u0000-\u00ff are genuinely >> unlikely to come up by mistake > > I know... That's been mentioned several times between here and c.l.t. > > But "genuinely unlikely" still sounds far too much like "undiscovered bug" for my comfort. To paraphrase myself: there are two mutually exclusive use cases: 1. you care about nulls, so you have to filter this special value (e.g. \uffff) out of the strings you get from external sources; they are invalid anyway AFA Unicode is concerned; 2. you don't care about nulls, so you just pass strings around. You won't get any bug with these special chars in case #2, which happens to be the general case (and includes every piece of Tcl code written so far). Case #1 requires explicit coding at some point, but so do all the alternative solutions proposed on this thread and elsewhere. Bottom line: zero effort needed for null-oblivious applications. |
From: <lm...@bi...> - 2008-06-21 12:48:13
|
> Of course, it's not that you're trying to make tcl better. If this were true, or were held to be true, so be it. But for better or worse, I'm trying to make tcl be better. It may be that I'm so wrong that I'm making it worse. As soon as someone can show me that that is what I'm doing I'll shut up. So far, you're not doing a good job if that is your goal. -- --- Larry McVoy lm at bitmover.com http://www.bitkeeper.com |
From: Colin M. <co...@ch...> - 2008-06-21 11:27:20
|
Larry McVoy wrote: > On Sat, Jun 21, 2008 at 01:22:56PM +1000, Colin McCormack wrote: > >> >> Here's my +1 for STFU. >> > > Hey, I'm OK with that. As soon as you move things forward better than I do. > Confusing activity for progress. > As soon as you contribute more effort than I do. Confusing effort for quality. > As soon as you spend more > money than I do. Confusing input with output. > For tcl being better. > Of course, it's not that you're trying to make tcl better. The reasons you're pushing NULL is that you made an error in misunderstanding what List could do for you, in L. That's the only reason. I don't think 'able to support L's poor design choices' is the same as 'better.' > I'll grant you that you are better than me at making tcl be the same. > Personally? I'm interested in making tcl 'be the same' as tcl, only moreso. I'm completely uninterested in making tcl 'be the same' as C, PERL, or whatever your current '3xfaster' fantasy is. I really do think you're mistaken in your apparent belief that NULL is right for tcl. No harm there. I also think you're obnoxiously devoted to tenaciously clinging to your error. That's not so good. I suspect you're doing it purely because you don't want to absorb the cost of your L implementation error (or myopia.) That's really bad. What's worst of all is abusing the good graces and sense of duty of the people who actually contribute to tcl by monotonous repetition of thoroughly refuted specious arguments, invincible ignorance, and argumentum ad nausea. Colin. |
From: Frédéric B. <fre...@fr...> - 2008-06-21 10:53:45
|
miguel sofer wrote: > Frédéric Bonnet wrote: >> But what if null is NOT a value? I know this sounds crazy, but just >> think about it: no value means no string rep; ergo, null as a >> non-value doesn't break EIAS. This also implies that such a null >> cannot be a valid operand in any operation that expects values; any >> occurrence of null in such operations generates an exception. So in >> the end we get something close to Smalltalk's nil. >> >> So: >> >> set a [null] >> [isnull $a] --> 1 >> [isnull foo${a}bar] --> BANG! null used in string operation >> expr {$a eq $a} --> 1 > > I fear I do not understand ... what do *you* mean by value? A string, since all values has a string representation. Reciprocally, something that has no possible string representation is not a value. > In my understanding, "any operation that expects values" is all of them > by definition: a value would be "anything that is acceptable as an > argument to a command or a return from same". Well, it's a bit ambiguous. I meant: operations that need the string values of its argument, either directly or not (i.e. if the object already has an internal rep, which implies that it can generate a valid string rep). This means that null can be tested for strict equality but is excluded from string operations. It can also be put into null-aware containers, but is not a valid container itself (since containers must have a string rep). Here null would not be a value but still could be passed as an argument to a command. The way it's treated is totally up to this command: it could be accepted, ignored or generate an exception. |