Carrot Strings'em

[m i c h a e l]

Here's a short quiz:

char int string sym. Which one doesn't belong?

Did you guess int, thinking it was the number that doesn't belong? No, that's not what I'm thinking of here. sym? No. Not that one either. With a 50/50 chance left, let's cut to the chase and reveal that it is the . . . one and only . . . data type we all know and love . . . string!

Why do I say string doesn't belong? That's personal and the trauma still haunts me. No, wait. That was my experience with software development methodologies ;-) I'm kidding, of course (you did notice the plethora of smilies in my posts, didn't you? :-)

Maybe now that sym and int are going by their shorter, hipper names, perhaps we could shorten string to str so that string doesn't feel neglected ;-)

Just another building-top observation from a friendly cuckoo bird* :-)


m i c h a e l

P.S. Melissa and I have been adopted by two orphaned starlings and the half-hourly feedings are beginning to take their toll on our extra activities. I have a few pieces for the newlisper blog in the works, but I've really slowed down to a writing crawl. Until Franny and Zooey are able to eat on their own, my visits to the club will probably be a little less frequent.

*Although I always fancied myself a crow: maligned, misunderstood, outcast ;-)

[cormullion]

I can see why you like newLISP - your writing is kind of recursive and self-referential...

:-)

[m i c h a e l]

I can see why you like newLISP - your writing is kind of recursive and self-referential...

:-)

How can this be? I? Me? Yours truly? This being we call michael? I repeat, How can this be? :-)


m i c h a e l

[Lutz]

Maybe now that sym and int are going by their shorter, hipper names, perhaps we could shorten string to str so that string doesn't feel neglected ;-)

I have had sleepless nights over this issue going back and forth on this, really! :), over the years several function names have been shortened and people seem to be generally happy with it, but on 'string' or 'str' I cannot decide.

My current take on 'string' is, that 'string' is much more than a type converter or caster, 'string' also "strings", meaning it appends different strings. One blogger wrote an entire post about it: http://newlisper.blogspot.com/2006/01/s ... wlisp.html ;)

It is a diffcult issue ... perhaps we should vote on it? What do others think?

Meanwhile do a (constant 'str string) to have available both.

Lutz

[Sammo]

I much prefer 'string' over 'str' and, by the way, I strongly prefer 'symbol' over 'sym.'

My preferences come, naturally, from my experience with other languages in which "int" and "char" were common and so came to feel natural to me. Moreover, each is fairly pronounceable.

How would "str" be pronounced? I don't think it would pass Kernighan's "telephone test," and besides, my fingers are used to typing "string" and would have to be retrained to shorten that to "str."

I suppose I could execute a (constant 'string str) command if you were to make the change, but I'd rather you leave 'string' alone.

[Dmi]

I prefer to use "str" for my own symbols.
Also I often use self-decribing names like "spool-report-summary" etc., so "string" makes no much overhead, but is looking more natural when I read the code :-)

[HPW]

I completly agree with Sammo.
As a old autolisper I have also a 'strcat'.
;-)

[Lutz]

Lets review them all:

(1) string stays string.

(2) symbol will be taken off the deprecated list in the manual allowing both (it never was taken out the internal symbols table)

(3) integer was moved to 'int' and is on the deprecated list. in this case the shorter form makes nuch sense because 'int' is mostly used as a type caster and widely used in other languages in it's short form, but should we leave 'integer' too and take it from the deprecated list (never was removed from ther table)?

(4) get-integer was moved to 'get-int' and is on the deprecated list, it is not used very frequently, mostly for importing libraries for accessing binary structures. 'get-int' should go the same direction as 'int' as you could say they constitute a family. Should the old form be taken out from the internal table?

Last not least: should 'str' be added allowing both? We would then allow short or long form in types accross the board for string/str interger/int symbol/sym ?

Lutz

ps: and this whole multiple names discussion is limited to the type names. This is not the beginning of giving each function more than one name ;)

[newdep]

Its all about what "Flavor of MilkShake" we like..

I like a more human way of drinking milkshakes,
which puts me directly in the row of Shakers that like: "Strawberry Vanilla Chocolate"
and not in the "very-very-Fast-Food" chain of " Str Van Cho"


;-)

Regards, Norman

[newdep]

Actualy, Lets stick with the full naming and put the short-version
inside the init.lsp perhpas? Or is some extra #define not eating
much bytes?

Norman.

[noah]

In Perl, there's an English module, which provides verbose syntax alternatives.

Maybe someone will put together an init.lsp that contains verbose versions of types and functions and offer it on the website?

-Noah

[m i c h a e l]

I have had sleepless nights over this issue going back and forth on this, really! :)

Sorry, Lutz. I did not want to stir up memories of bad dreams ;-)

My current take on 'string' is, that 'string' is much more than a type converter or caster, 'string' also "strings", meaning it appends different strings.

I see what you mean.

How would "str" be pronounced? I don't think it would pass Kernighan's "telephone test,"

When I first learned that the char type in C was pronounced care or charr, I thought both sounded ridiculous. It took a long time to feel natural saying it (I settled on the care pronunciation) out loud. The value of having the "telephone test" is not in question. Communicating these things verbally to others becomes a farce when there are no easy and agreed upon pronunciations for the names. Forth has pronunciations for all of the standard words. We're talking cryptic symbols like:

Code: Select all

! (store)
>r (to r)
r< (r from)
@ (fetch)

In answer to how to pronounce str, I would probably use stir. If that sounds stupid to you, remember about care and charr :-)

In Perl, there's an English module, which provides verbose syntax alternatives.

I like what Noah is suggesting here. Those of us who prefer the names fully spelled out would then have that option. Sam, Dmi, Hans-Peter, and Norman could use symbol and string. But then there's the problem of the short names still hanging around. As Dmi said, he uses str as a variable name. It would be nice to satisfy everyone if possible, but the flashlight beam seems to be missing the spot where all concerned feel satisfied by the solution. I'm still somewhat neutral, as I think those using the language most are the best judges of The Right Thing. I lean toward the terse camp for scripting languages, though (e.g., Ruby's use of the name initialize for the constructor has always been a sore spot for me).


m i c h a e l

[HPW]

Lets review them all:

(1) string stays string.

(2) symbol will be taken off the deprecated list in the manual allowing both (it never was taken out the internal symbols table)

(3) integer was moved to 'int' and is on the deprecated list. in this case the shorter form makes nuch sense because 'int' is mostly used as a type caster and widely used in other languages in it's short form, but should we leave 'integer' too and take it from the deprecated list (never was removed from ther table)?

(4) get-integer was moved to 'get-int' and is on the deprecated list, it is not used very frequently, mostly for importing libraries for accessing binary structures. 'get-int' should go the same direction as 'int' as you could say they constitute a family. Should the old form be taken out from the internal table?

Last not least: should 'str' be added allowing both? We would then allow short or long form in types accross the board for string/str interger/int symbol/sym ?

Lutz

What the case now with 8.9.7/9.0?

symbol is eliminated.
integer is still on the deprecated list. Not clear!
get-integer is also on the list and not clear.
str still not valid.

The most interesting for me is 'integer' since I used it quite a lot in the past.
Do I have to go to the source (like with symbol) to keep running in the next future?

[Lutz]

(1) The decision to eliminate the deprecated 'symbol' for 'sym' first, was the fact that there are already to very similar looking functions with 'symbols' and 'symbol?' and 'sym' is used relative frequently when making dictionaries. It is not really used as a type converter/caster. At least that is not the way you look at it when using it. (*)

(2) 'get-integer' will be next and relative easy, because its is not used that often, and then only by more advanced users when writing import module code, and as you point out 'int' is a keyword people are very familiar with.

(3) There is a lot of 'integer' legacy code out there but elimination will come too. People should convert to 'int' the earlier, the better.

Probably 'get-integer' and 'integer' should go at the same time replaced by the shorer 'get-int' and 'int'.

(4) No plans for deprecating 'string', str just doesn't feel right too me as a built-in. Also 'string' is more than a type converter/caster frequently used for appending with implicit conversion.

Lutz

(*) for anybody wanting to keep 'symbol': you can always do: (constant (global 'symbol) sym) to get it back.

[HPW]

...the earlier, the better.

Lutz,

Thanks for the info!
Now I know what have to be done.