January 21, 2005 Re: What is the difference between 'is' and '==='? | ||||
---|---|---|---|---|
| ||||
Posted in reply to parabolis | In article <cspmau$1e2o$1@digitaldaemon.com>, parabolis says... > >I think you missed the larger point that "isnt" is better than nothing which is what we have since "is not" is not a single word. The phrases "at least" and "at most" suffer from the same problem that keeps "is not" from being possible while lacking a contractable form. > What problem? Is there a reason why an operator has to be a single token? Using 'is not' requires the addition of an extra keyword 'not', which might be useful to combine with other keywords elsewhere, whereas 'isnt' adds a keyword with a single use. Parsers shouldn't have any trouble with this sort of thing (long int and unsigned long in C/C++, for instance). It should be a trivial transformation in the grammar, like combining adjacent string constants into one. I could see why one might want each operator to be a single lextoken, for reasons of style or cleanliness rather than technical reasons. Personally I think that minimizing the number of keywords is also important for cleanliness. |
January 21, 2005 Re: What is the difference between 'is' and '==='? | ||||
---|---|---|---|---|
| ||||
Posted in reply to agent.smith | agent.smith@archvillain.com wrote:
> In article <cspmau$1e2o$1@digitaldaemon.com>, parabolis says...
>
>>I think you missed the larger point that "isnt" is better than nothing which is what we have since "is not" is not a single word. The phrases "at least" and "at most" suffer from the same problem that keeps "is not" from being possible while lacking a contractable form.
>>
>
> What problem?
The problem that D supports Unicode to make it internationally usable but still has only English keywords. Just using "is" is bad enough but to take that a step farther and assume all languages have a copula, an individual word for negation and that the negation word follows the copula is rather dangerous. Of course you may very well fluently speak all the languages spoken on the planet but I do not and so it seems like a problem to me.
|
January 21, 2005 Re: What is the difference .. really: Why are typenames keywords? | ||||
---|---|---|---|---|
| ||||
Posted in reply to agent.smith | agent.smith@archvillain.com wrote:
> My example was C code, I was making a point which
> everybody here probably already knows (sorry for any confusion)
> as a step towards my real point that typenames in D don't
> need to be reserved words. Precisely because the D language,
> unlike C/C++, does *not* need them to be so in order to direct parsing.
> And making too many things keywords has some bad side-effects.
My point was that cast, one of the "long list of keywords", serves the purpose of allowing all casts to be identified by the lexer.
|
January 21, 2005 Re: What is the difference between 'is' and '==='? | ||||
---|---|---|---|---|
| ||||
Posted in reply to parabolis | In article <csrlnk$npm$1@digitaldaemon.com>, parabolis says... > >agent.smith@archvillain.com wrote: >> In article <cspmau$1e2o$1@digitaldaemon.com>, parabolis says... >> >>>I think you missed the larger point that "isnt" is better than nothing which is what we have since "is not" is not a single word. The phrases "at least" and "at most" suffer from the same problem that keeps "is not" from being possible while lacking a contractable form. >>> >> >> What problem? > >The problem that D supports Unicode to make it internationally usable but still has only English keywords. Just using "is" is bad enough but to take that a step farther and assume all languages have a copula, an individual word for negation and that the negation word follows the copula is rather dangerous. Of course you may very well fluently speak all the languages spoken on the planet but I do not and so it seems like a problem to me. This is a point which had not occurred to me; but I'm trying to understand how it affects the question of whether 'is not' is any worse than 'isnt'. You are referring I think, about the difficulty of understanding 'is not' vs. 'isnt', or 'isnot', or vs. some arrangement of punctuation marks, for a non-anglophone-- this is an interesting point. I've never programmed in a language in which the 'words' aren't those of my native tongue, so I can only guess at the difficulties involved. I would suspect the concepts of programming easily transcend (or overwhelm) the difficulties of a few characters or a few syllables that aren't in the language or order you are used to -- I would be glad to hear from someone who can speak to this. I have worked with many Russian and French-speaking programmers and the topic just never came up. I took two years of high school mathematics (which wound up covering most of my 1st year engineering math and much of the 2nd year) completely in French, and although I always fared quite poorly at actual French, I had no difficulty learning the verbs and adjectives, and different methods of pronouncing mathematical constructs in French. Or, at least, it was almost always less difficult than the math itself. I admit there is something compelling about the idea of a language where all expressions are in symbolic form, so it transcends language. But you'll still have (a) things like .length; (b) all the "bigger" keywords like 'while' and 'public'; (c) libraries and APIs full of words. And aren't we there already, to a large degree? Consider all the nonsense words we deal with, wchar, typedef, frexp, cdecl, ... yacc, http... it never occurred to me until right now how little meaning they derive from language as opposed to just being glued together from other computer words. And, consider APL. Was that really a good idea? I guess what I'm saying is, if you choose to do 'is' and 'isnt' as 'ek' and 'nis ek', it wouldn't slow me down much. Maybe I'm wrong. I am completely missing the point? If a language doesn't have a separate 'is' word, speakers of the language will still grasp the concept easily. If the language is so unusual that it hasn't introduced them to the concept, they may need more help than a few letters can give them -- see "Seeing Voices" by Oliver Sacks, there is a discussion of how failure to be introduced, as a toddler, to basic abstract notions (e.g. a 'person', as opposed to 'Bob' or 'Mary') severely impairs learning. These concepts are universal. |
January 21, 2005 Re: What is the difference .. really: Why are typenames keywords? | ||||
---|---|---|---|---|
| ||||
Posted in reply to parabolis | In article <csrmji$or4$1@digitaldaemon.com>, parabolis says... > >agent.smith@archvillain.com wrote: >> My example was C code, I was making a point which >> everybody here probably already knows (sorry for any confusion) >> as a step towards my real point that typenames in D don't >> need to be reserved words. Precisely because the D language, >> unlike C/C++, does *not* need them to be so in order to direct parsing. >> And making too many things keywords has some bad side-effects. > >My point was that cast, one of the "long list of keywords", serves the purpose of allowing all casts to be identified by the lexer. [Well, by the parser, but without help from the symbol table]. But, yes, exactly right. And thus, in cast(wchar), 'wchar' doesn't need to be a keyword. Not like C. Thus that *one* word 'cast' (well, maybe not *just* that), means you could take 20+ other words out of the list. I wish I'd made that exact point before, thanks. So why not take them out? The work has been done, why not reap the benefits? I know I'm missing a really compelling argument why it's a Bad Thing to have too many keywords. All I can say is, take all the languages you know and love or hate, and place them on a scale according to the number of keywords they have, and decide in what neighborhood you'd like to be. Maybe a language isn't good or bad because of how many keywords it has; maybe it tends to be the other way around; but there just seems to be a correlation. It seems that well designed languages don't need a lot of keywords, and many keywords are often used as a crutch to help parse a poorly designed language (one could argue that C typedefs are dynamically defined keywords, for the precise purpose of crutching the parser). Of course, you can go too far in the other direction and have Lisp or APL (not to impune anything but their appearance). D has been well-designed to the point where it doesn't need keywords for all the built-in types, or for 'true' and 'false' (these could be predefined const values like in Pascal). So why are they still in the list?? |
January 22, 2005 Re: What is the difference between 'is' and '==='? | ||||
---|---|---|---|---|
| ||||
Posted in reply to agent.smith | agent.smith@archvillain.com wrote: > In article <csrlnk$npm$1@digitaldaemon.com>, parabolis says... > >>agent.smith@archvillain.com wrote: >> >>>In article <cspmau$1e2o$1@digitaldaemon.com>, parabolis says... >>> >>> >>>>I think you missed the larger point that "isnt" is better than nothing which is what we have since "is not" is not a single word. The phrases "at least" and "at most" suffer from the same problem that keeps "is not" from being possible while lacking a contractable form. >>>> >>> >>>What problem? >> >>The problem that D supports Unicode to make it internationally usable but still has only English keywords. Just using "is" is bad enough but to take that a step farther and assume all languages have a copula, an individual word for negation and that the negation word follows the copula is rather dangerous. Of course you may very well fluently speak all the languages spoken on the planet but I do not and so it seems like a problem to me. > > > This is a point which had not occurred to me; but I'm trying to understand > how it affects the question of whether 'is not' is any worse than 'isnt'. You mentioned learning french which is a good example. Negation in french involves 3 words ne, est and pas. The french contradiction solution would give is=nest and not=pas. However we would be expecting is to remain unchanged in the affirmative or the negative. So you could probably get by assigning is=est and not=pas. However isnt is a whole new keyword which would allow nestpas. So without going very far away from the roots of English (and the only other language I have really studied) we are already having trouble getting everything to work out if we use is not. > I've never programmed in a language in which the > 'words' aren't those of my native tongue, so I can only guess at > the difficulties involved. I would suspect the concepts of programming > easily transcend (or overwhelm) the difficulties of a few characters or a > few syllables that aren't in the language or order you are used to I would largely agree but with the caveat that it speeds learning the language if you already have an intuitive feel for how the various parts work. I know almost no Russian or Norse but I am pretty confident I could pick up is, if, else, do, while, etc in a day or so. However it would not be without some difficulty that I adjusted to actually reading and writing these things from day to day. > I admit there is something compelling about the idea of a language where all > expressions are in symbolic form, so it transcends language. But you'll > still have (a) things like .length; (b) all the "bigger" keywords like 'while' > and 'public'; (c) libraries and APIs full of words. I am pretty sure (c) is beyond the scope of D's language spec. It is mostly (a) and (b) that concern me. > And aren't we there already, to a large degree? Consider all the > nonsense words we deal with, wchar, typedef, frexp, > cdecl, ... yacc, http... it never occurred to me until right now how > little meaning they derive from language as opposed to just being > glued together from other computer words. I think I may be the wrong person to ask. I am rather abnormal in that they all contain a great deal of meaning for me. Just recently I found myself wondering about GNU's relation to Unix but quickly solved the problem by rephrasing the question as "Is GNU Unix?". > And, consider APL. Was that really a good idea? Actually I imagine APL's symbols seem more familiar to an anglo reader than if clauses would to a mandarin reader. However I am not suggesting a pure symbolic language. I want to see if clauses in mandarin and english. |
January 22, 2005 Re: What is the difference between 'is' and '==='? | ||||
---|---|---|---|---|
| ||||
Posted in reply to parabolis | In article <css7cg$1c78$1@digitaldaemon.com>, parabolis says... > >You mentioned learning french which is a good example. Negation in french involves 3 words ne, est and pas. The french contradiction solution would give is=nest and not=pas. However we would be expecting is to remain unchanged in the affirmative or the negative. So you could probably get by assigning is=est and not=pas. However isnt is a whole new keyword which would allow nestpas. So without going very far away from the roots of English (and the only other language I have really studied) we are already having trouble getting everything to work out if we use is not. I may have missed the point. Are we talking about creating variants of D where keywords are spelled in other languages? Wow. For what it's worth, I think that "nest pas" (without the ') could be less palatable to a francophone than a simple foreign phrase like 'is not'. Even with my few years of high school French, I found that reading the language without the proper punctuation and accents is like reding weth rong spelyng. So you'd probably want to deal with that somehow. If this is the plan, then, yes, you probably want to stick to one token per operator. I don't see why you can't define token combining rules, so that the two keywords 'is' 'not' in english D combine to the same token which is generated by a single Hebrew word, but I also can see why this might not a good idea. > >> I've never programmed in a language in which the >> 'words' aren't those of my native tongue, so I can only guess at >> the difficulties involved. I would suspect the concepts of programming >> easily transcend (or overwhelm) the difficulties of a few characters or a >> few syllables that aren't in the language or order you are used to > >I would largely agree but with the caveat that it speeds learning the language if you already have an intuitive feel for how the various parts work. I know almost no Russian or Norse but I am pretty confident I could pick up is, if, else, do, while, etc in a day or so. However it would not be without some difficulty that I adjusted to actually reading and writing these things from day to day. I tend to agree but - and again I'm trying to imagine what it's like- if I could write variable and function names in my native language (and not just comments) complete with diacritical marks, etc. then it probably makes a bigger difference. I.e. if I have to adjust to latin alphabet for all my identifiers, then reading a few keywords in latin would be no big deal. Is the plan to support unicode identifiers, with all that implies for linking, etc? I don't see why not - there's a lot of messy practical issues though. For instance, error messages from ld would need to be in unicode, or else they could list undefined symbols as gibberish mangled ASCII. >> I admit there is something compelling about the idea of a language where all >> expressions are in symbolic form, so it transcends language. But you'll >> still have (a) things like .length; (b) all the "bigger" keywords like 'while' >> and 'public'; (c) libraries and APIs full of words. > >I am pretty sure (c) is beyond the scope of D's language spec. It is mostly (a) and (b) that concern me. libc was beyond the C language spec initially; it still is, in some sense, but it's hard to separate the two in practice. As in my previous point, unless you translate the standard libraries, you aren't covering much of the actual namespace. But the core language should be dealt with ahead of the libraries, I guess. > >> And aren't we there already, to a large degree? Consider all the >> nonsense words we deal with, wchar, typedef, frexp, >> cdecl, ... yacc, http... it never occurred to me until right now how >> little meaning they derive from language as opposed to just being >> glued together from other computer words. > >I think I may be the wrong person to ask. I am rather abnormal in that they all contain a great deal of meaning for me. Just recently I found myself wondering about GNU's relation to Unix but quickly solved the problem by rephrasing the question as "Is GNU Unix?". That's Gnot the point. Do you think about that every time you read it, or do you just associate the term with the entity? If you had no idea what 'GNU' stood for, but had come to understand its important non-relation to Unix through the same years of experience you have already have, would that hinder you much? I don't mean to sound humourless, but my point exactly is that you *didn't* solve the problem that way; in fact, you need to understand the relationship in order to get the joke. It's conceptually recursive, as well as lexically recursive. So, the roots of the term 'gnu' continue to be a source of amusement, (which in itself has excellent mnemonic value), but you can't claim it's descriptive, in the sense that, say, "Statten Island Ferry" is. When you look at a while loop, do you usually pause to consider that the word is also a noun, meaning 'a period of time'? If you do, then I concede your strangeness. I've noticed that a lot of magazines, due presumably to editorial policy, won't print the term "ASCII" without following the first occurrence by the usual clumsy phrase (Amer... ...change). Does that clarify anything for anyone? If someone doesn't know what ASCII is, I doubt that having the mnemonic spelled out will help them much. They might, for instance, suspect that there could be a European or Canadian SCII. "The way computers code symbols as numbers" takes less ink and is probably much more helpful. My point is, ASCII in everyday use is really just a symbol, it roots faded from its meaning. Another excellent example is RS-232. That's a standard I've never seen; it stopped being followed as a standard long ago, and the term kept on being used to describe things that vaguely conformed to a small part of the standard. Everybody knows what you're referring to, nobody knows what the term means, and we get on fine. Just let me find that 9-pin adapter. |
January 22, 2005 Re: What is the difference between 'is' and '==='? | ||||
---|---|---|---|---|
| ||||
Posted in reply to agent.smith | agent.smith@archvillain.com wrote:
>
> I've never programmed in a language in which the
> 'words' aren't those of my native tongue, so I can only guess at
> the difficulties involved. I would suspect the concepts of programming
> easily transcend (or overwhelm) the difficulties of a few characters or a
> few syllables that aren't in the language or order you are used to -- I
> would be glad to hear from someone who can speak to this. I have worked with
> many Russian and French-speaking programmers and the topic just never came up.
>
Only once (I mean exactly once) I had a problem with programming in language that isn't mine.
I started programming when I was about 8 when my dad taught me Basic (GW-Basic). Now, Basic has (or had) the "input" keyword, but in Spanish, p's and b's can't be preceded by n's, but m's instead. So in one of my first programs I wrote "imput" (I'm also some kind of freak with grammar, at least in Spanish), and Basic obviously complained. It took me a while to know what was going on, but it's never bit me again.
But if you search in old posts in the old D newsgroup, you'll find a post by me asking to have the ability to specify in what language (meaning English, Spanish, French, etc.) we wanted to code. You can laugh if you want. I do.
_______________________
Carlos Santander Bernal
|
January 22, 2005 Re: What is the difference between 'is' and '==='? | ||||
---|---|---|---|---|
| ||||
Posted in reply to agent.smith | agent.smith@archvillain.com wrote: > In article <css7cg$1c78$1@digitaldaemon.com>, parabolis says... > >>You mentioned learning french which is a good example. Negation in french involves 3 words ne, est and pas. The french contradiction solution would give is=nest and not=pas. However we would be expecting is to remain unchanged in the affirmative or the negative. So you could probably get by assigning is=est and not=pas. However isnt is a whole new keyword which would allow nestpas. So without going very far away from the roots of English (and the only other language I have really studied) we are already having trouble getting everything to work out if we use is not. > > > I may have missed the point. Are we talking about creating variants > of D where keywords are spelled in other languages? Wow. It is more of an intellectual inquisition into the possibility and ramifications of creating one international D. > For what it's worth, I think that "nest pas" (without the ') > could be less palatable to a francophone than a simple > foreign phrase like 'is not'. Even with my few years of high > school French, I found that reading the language without the > proper punctuation and accents is like reding weth rong spelyng. > So you'd probably want to deal with that somehow. > > If this is the plan, then, yes, you probably want to stick > to one token per operator. I don't see why you can't define > token combining rules, so that the two keywords 'is' 'not' > in english D combine to the same token which is generated > by a single Hebrew word, but I also can see why this might > not a good idea. That is an interesting idea but then you have three tokens involved in the english affirmative and negative and two of them are identical - is, is and not. > I tend to agree but - and again I'm trying to imagine what it's like- > if I could write variable and function names in my native language > (and not just comments) complete with diacritical marks, etc. then > it probably makes a bigger difference. I.e. if I have to adjust to > latin alphabet for all my identifiers, then reading a few keywords > in latin would be no big deal. Is the plan to support unicode identifiers, > with all that implies for linking, etc? I don't see why not - there's http://www.digitalmars.com/d/lex.html "Identifiers start with a letter, _, or unicode alpha, and are followed by any number of letters, _, digits, or universal alphas. Universal alphas are as defined in ISO/IEC 9899:1999(E) Appendix D. (This is the C99 Standard.)" >>>I admit there is something compelling about the idea of a language where all >>>expressions are in symbolic form, so it transcends language. But you'll >>>still have (a) things like .length; (b) all the "bigger" keywords like 'while' >>>and 'public'; (c) libraries and APIs full of words. >> >>I am pretty sure (c) is beyond the scope of D's language spec. It is mostly (a) and (b) that concern me. > > > libc was beyond the C language spec initially; it still is, in > some sense, but it's hard to separate the two in practice. > As in my previous point, unless you translate the standard libraries, > you aren't covering much of the actual namespace. But the core language > should be dealt with ahead of the libraries, I guess. Let me rephrase my concern. In the future compilers will be multi-lingual. That raises questions like how did they get that way and what does multi-lingual really mean? Are Arabic Numerals international enough or is there a need to support Roman Numerals? >>>And aren't we there already, to a large degree? Consider all the >>>nonsense words we deal with, wchar, typedef, frexp, >>>cdecl, ... yacc, http... it never occurred to me until right now how >>>little meaning they derive from language as opposed to just being >>>glued together from other computer words. >> >>I think I may be the wrong person to ask. I am rather abnormal in that they all contain a great deal of meaning for me. Just recently I found myself wondering about GNU's relation to Unix but quickly solved the problem by rephrasing the question as "Is GNU Unix?". > > > That's Gnot the point. Do you think about that every time you > read it, or do you just associate the term with the entity? I apologize for misrepresenting what I was saying so horribly. I implied wrongly in my paraphrasing of the event that understanding this thing was GNU came before my understanding it was not Unix. I was going to share some clearer examples with you but I think I will just make the point that acronyms are useful as learning devices. Try to memorize the letters on the list (but not the order): I, A, F, N, S, B, C, A, I Knowing I made the list by scrambling the letters in fbi, cia and nsa should make learning the list simple. So then what makes for a better mnemonic than calling an statement that is executed only when the expression it comes with evaluates to a non-zero value? Well calling it an if statement is quite helpful unless you are French in which case replacing si with if aids the clarity. |
January 22, 2005 Re: What is the difference between 'is' and '==='? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew | Matthew wrote:
> "Walter" <newshound@digitalmars.com> wrote in message news:cspa3k$v95$2@digitaldaemon.com...
>
>>"nail" <nail_member@pathlink.com> wrote in message
>>news:cson1b$5f6$1@digitaldaemon.com...
>>
>>>>PS.
>>>>I still think that we need 'isnt' for '!=='
>>>
>>>In this case isnt must be :)
>>>
>>>What about future? Does === will become deprecated?
>>
>>Yes, use "is" from now on. The === turned out to be a problem distinguishing
>>from == with some fonts.
>
>
> So're we getting an 'isnt'?
>
> if(!(x is null))
>
> is never going to be an attractive form
>
>
I find this form quite appealing. So sue me.
Lars Ivar Igesund
PS Welcome back to the NG (Your book looks great, although I've just looked at the TOC :)
|
Copyright © 1999-2021 by the D Language Foundation