Date: Mon, 21 Dec 1998 01:25:21 -0800 (PST) From: "Daniel C. Sobral" <dcs@newsguy.com> To: mike@smith.net.au Cc: current@FreeBSD.ORG Subject: Re: BootFORTH - demo floppy Message-ID: <199812210925.BAA09284@newsguy.com>
next in thread | raw e-mail | index | archive | help
At Mon, 21 Dec 1998 00:49:05 -0800, you wrote > >> >> 3) I noticed "evaluate" is working with null-ended string, ignoring >> >> completely the count on the stack. Not good. > >We don't like counted strings. They suck for innumerable reasons, and >if the only reason for having them there is "tradition" (ie. there is >no reason *not* to take them away) then they can damn well die. 8) Well, I have never seen a "reason" aside from needlessly limiting the size of one string (at 32 bits, that ought to be a joke, but...), which is well balanced by needlessly limiting what can be inside a string. But, as you say below, "having said that..." >Having said that, I get the distinct impression that we're stuck with >these deadweights. Hardly. ANS Forth removed the count from the string itself for this precise reason. So, s" <string>" must return the memory to the string, as well as it's size. It is up to the implementation to decide whether a zero must be appended to the end (giving our specific application, sure it must), and the count being returned on the stack is a given (ie, you have that information as a side effect of parsing). Of course, "move" must act as strncpy, not strcpy, and so on. But you will notice that the words that assume a count with the string have been made obsolete. >> Now, adding nulls to the end of the string is very easy with count based >> strings (as long as you are not working with a substring), and I have nothing >> against doing it. But having "evaluate" operate on null-terminated strings is >> the same as having strncmp operate on null-terminated strings: it's against >> standard and intent. > >That's something you're welcome to take up with Mr Ficl; bear in mind >though that we're talking about something that has to work fairly close >to a much more significant C application. If trading between the two >formats is a good idea from the efficiency point of view, that's >probably the way to go. > >If you have any more concrete reasons (like it breaks something >significant), then that's something I'd be happy to address, but "it's >not normally done like that" is perhaps less important than "it's easy >to work with in this context". Nobody else seems to have trouble interfacing Forth with C, so I just don't see I case here. It's not "tradition". It is the ANS Forth standard. If you want an evaluate which works with null-terminated strings, go ahead and define evaluate0 or something. But needlessly making it incompatible with a published standard is, well, it is stupid. I did not have any trouble getting around the need for a null-terminated string, but it did took me some time to figure out what the "bug" in "my" code was. Do you see my point here? I'm not against making it easier to interface with the "C" environment. But you can do that without breaking compatibility. There is a lot of room for that. The standard words for allocating strings won't mind automatic appending a null, you can define words like "strcpy", "strlen" and "strcmp" doing exactly what you would expect them to, and there even some more obscure restrictions made in ANS Forth just so such interfacing can be made more painlessly. But if you change the behavior of a standard word, instead of just defining a new word, you not only make it "incompatible" with standard programs (or, more to the point to us, libraries). You make it incompatible with Forth programmers. Just for the sake of using "evaluate" instead of "evaluate0", I must say I don't really see a gain on _your_ side. create buffer buffersize allot : evaluate buffer over + 0 swap c! buffer swap move buffer evaluate0 ; Writing the two lines above is much faster than finding the "bug", I assure you. -- Daniel C. Sobral dcs@newsguy.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812210925.BAA09284>