Re: String?
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Jun 01, 2004
- 721 views
On Mon, 31 May 2004 14:27:12 -0700, Nicholas Koceja <guest at RapidEuphoria.com> wrote: >First off, Why shuold the program differenciate from these two? As per my previous post, not much apart from the loss of the obvious, "common sense" meaning which is plain discarded, at a low level. >take this example: > The "key.ex" program. >}}} <eucode> >-- find out what numeric key code is generated by any key on the keyboard >-- usage: >-- ex key > >integer code > >puts(1, "Press any key. I'll show you the key code. Press q to quit\n\n") >while 1 do > code = get_key() > if code != -1 then ><b> printf(1, "The key code is: %d\n", code)</b> > if code = 'q' then > exit > end if > end if >end while ></eucode> {{{ >In the program, it thinks of code as an 'integer'. With a string typpe, you >could NOT have code as integer, it would have to be OBJECT, since a Chaacter >could be aan integer, or a String. the key statement is in bold. If there >was a String type, this statement would cause an error. You lost me completely. <aside>I would fight tooth and nail against a "Character" type... can we just agree that is not the issue here?</aside> . Having a string type won't cause an error; defining some variable as a string when it gets assigned either a string or an integer would, but no different to defining a sequence var and assigning an int to it. Supplying a string param to printf when an integer was expected also might cause an error, but why any more so than a sequence? > Furthermore, if you >defined double-quotes as a "String", then the '%d' would cause the error, since >a "string" can not have a decimal value. If you make it so that a "string" >can have one, you would be destroying what you tried to prove in the first >place. I fail to understand what you are trying to say here either ;-(( >Take a look at this: >}}} <eucode> >sequence string, seq >atom at > >string = "" >seq = {} >procedure same(object a) > if equal(string, a) then > puts(1, "TRUE\n\n") > else > puts(1, "FALSE\n\n") > end if >end procedure > >puts(1, "\"\" = {}\n") >same(seq) >puts(1, "\"abcd\" = {\'a\',\'b\',\'c\',\'d\'}\n") >string = "abcd" >seq = {'a','b','c','d'} >same(seq) >puts(1, "\"a\" = \'a\'\n") >string = "a" >at = 'a' >same(at) >while get_key() = -1 do > end while ></eucode> {{{ >This may make you think that there is no differenciation. Not for a moment. A string and a character (which I would prefer to keep as an integer) are indeed different. (I admit that I made that mistake once (implementing the now shelved pleumage), never again) >To tell you the honest truth, a "string" type would be pointless It might not add much extra functionality, in truth I agree. It would add a welcome degree of readability on the diagnostic side.. >, and would make Euphoria a tad slower. By a fair margin, I reckon. > If you were to include a string type, you would >have to change how Euphoria looks at sequences, and "strings", for that matter. >As you all know, Euphoria is a fast, and easy to understand (Not always easy to >learn) Programming language. As it states in "ed.doc", Euphoria uses pure >numbers. The smallet unit is an "atom". Atoms and Sequences are the ony two >explicitly defined types. An Integer is a type of atom, and an object can be a >sequence, as well as an atom. What I think we need to find out, is this >Question: >"What exactly is a String?" If a string is just defined as in BASIC: "A string >of >letters or numnbers." then yes, we could benifit from it. However, if a >string >is defined as a sequence of characters, then ANY seqence of positive integers >would >fit the description. Although the character page only goes to 255, you can >"print" >ANY positive integer. Well, yes, but that is another bit of a fudge and a clear indication that unicode support is a country mile away... > Try it yourself. Therefdore, the question of wether a string >type should be included or not all depends on the answer to the question: >"What exactly defines a String?" The fundamental thing I would claim is that if it looks like a string in the code you write, it is a string; if it looks like a sequence of numbers, it is a sequence of numbers. The point is to tally what the code reads like and how the trace window and the ? primitive operate. There should indeed be some (hopefully rarely used) functions to convert between the two, just in case you ever need them.. Pete