January 21, 2005
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
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
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
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
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
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
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
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
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
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 :)