> 
> 
> Yeah it's cool! They took a lot of the syntax of
> C, but dropped it's type system entirely.
> They also have a great standard library.
> They are very unix/linux oriented though, but
> that's also refreshing. At least they try to remain
> platform independant, something that cannot be
> said for ASP.
> 
> --
> Stijn
> OddesE_XYZ@hotmail.com
> http://OddesE.cjb.net
> _________________________________________________
> Remove _XYZ from my address when replying by mail
> 
> 


PHP is a lot of fun, especially the ability to change variable names inside your code! You could wreak a lot of havoc with that one... :)

"Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:ab6g1s$2gau$3@digitaldaemon.com...

> Yes, but of course it depends upon your definition of "ordinary mundane operations".  I think that if adding 10 to "A" is an ordinary mundane operation, there is a bug in the language design.  :-)

Is it? Sometimes, it is very convenient to operate on characters just as if they were numbers. Just consider converting string to integer...

"Pavel Minayev" <evilone@omen.ru> wrote in message news:ab7ia5$jo5$1@digitaldaemon.com...
> "Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:ab6g1s$2gau$3@digitaldaemon.com...
>
> > Yes, but of course it depends upon your definition of "ordinary mundane operations".  I think that if adding 10 to "A" is an ordinary mundane operation, there is a bug in the language design.  :-)
>
> Is it? Sometimes, it is very convenient to operate on characters just as if they were numbers. Just consider converting string to integer...

Well, that is normally done in some library so it is coded only a few times and thus is not mundane (no matter how many times the code is executed).  I didn't say such things should be impossible, just that they aren't "mundane and ordinary".

Also, except for hex values, the conversion of strings containing an "A" to an integer seems not very usefull.  :-)

--
 - Stephen Fuld
   e-mail address disguised to prevent spam

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3CD6DB74.3010802@estarcion.com...
> Stephen Fuld wrote:
> > "Walter" <walter@digitalmars.com> wrote in message news:ab426q$310j$2@digitaldaemon.com...
>  >>
> >>Needing casts for ordinary mundane operations means there's a bug in the language design.
> >
> >
> > Yes, but of course it depends upon your definition of "ordinary mundane operations".  I think that if adding 10 to "A" is an ordinary mundane operation, there is a bug in the language design.  :-)
>
> Surely the mundanity of adding 10 to A is a question of
> application domain, not language design? For example,
> doing math on characters is the bread and butter of
> crypto apps...
>
> -RB

Maybe it should just be allowed to add chars to chars, then you can just typecast the thing you're adding in, like so:

char b = a + '010';

or

char b = a + cast(char)10;

that's one less cast than is required if addition only works for ints, not chars.  Fairly acceptable.

Sean

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:ab8b1j$1bl5$1@digitaldaemon.com...
>
> "Russell Borogove" <kaleja@estarcion.com> wrote in message news:3CD6DB74.3010802@estarcion.com...
> > Stephen Fuld wrote:
> > > "Walter" <walter@digitalmars.com> wrote in message news:ab426q$310j$2@digitaldaemon.com...
> >  >>
> > >>Needing casts for ordinary mundane operations means there's a bug in
the
> > >>language design.
> > >
> > >
> > > Yes, but of course it depends upon your definition of "ordinary
mundane
> > > operations".  I think that if adding 10 to "A" is an ordinary mundane operation, there is a bug in the language design.  :-)
> >
> > Surely the mundanity of adding 10 to A is a question of
> > application domain, not language design? For example,
> > doing math on characters is the bread and butter of
> > crypto apps...
> >
> > -RB
>
> Maybe it should just be allowed to add chars to chars, then you can just typecast the thing you're adding in, like so:
>
> char b = a + '010';

Hmm this doesn't look good to me...


>
> or
>
> char b = a + cast(char)10;
>

This looks good. Doesn't this already work?
I think this is how it should be. Adding one
char to another seems perfectly reasonable
to me, especially now we have a dedicated
concatenation operator, so there won't be
any confusion.



--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

"Walter" <walter@digitalmars.com> wrote in message news:ab426p$310j$1@digitaldaemon.com...
>
> "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:ab3p6p$2p7t$1@digitaldaemon.com...
> > "Walter" <walter@digitalmars.com> wrote in message
> > news:ab1mag$s75$1@digitaldaemon.com...
> > <SNIP>
> > > ...I think of chars more as a special type of integers
> > > than as actual characters.
> > That's your C heritage speaking  :)
>
> Yes, it is. But remember I came to C from Pascal (I actually wrote a mini-Pascal compiler once), and never looked back.

Can you discuss why?  I am certainly not claiming that Pascal is "the perfect language", but IMHO, it is a better "starting point" for enhancement toward that goal than is C.  See for example, the Turing language, which bears about the same resemblance to Pascal as D does to C. (that is, similar syntax, but clean up a lot of the cruft and add some important features.)

http://www.holtsoft.com/turing/home.html

Turing has objects without all the complexity of C++ and it supports those things necessary for writing system software (like type cheats and absolute addresses), without easily allowing people to get in trouble with them. (They have written an OS in it.) It also adds the DBC stuff and a lot of other nice things.

Note that D has some things that I like that Turing doesn't, so this is not a slam toward D.  Just pointing out another similar but different approach.

--
 - Stephen Fuld
   e-mail address disguised to prevent spam

"Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:ab92qn$213l$1@digitaldaemon.com...
>
> "Walter" <walter@digitalmars.com> wrote in message news:ab426p$310j$1@digitaldaemon.com...
> >
<SNIP>
> >
> > Yes, it is. But remember I came to C from Pascal (I actually wrote a mini-Pascal compiler once), and never looked back.
>
> Can you discuss why?  I am certainly not claiming that Pascal is "the perfect language", but IMHO, it is a better "starting point" for
enhancement
> toward that goal than is C.  See for example, the Turing language, which bears about the same resemblance to Pascal as D does to C. (that is,
similar
> syntax, but clean up a lot of the cruft and add some important features.)
>

Pascal's syntax is actually one of the things I do not like about it. begin and end just get to be a pain in the you-know-where and do not really add much. The way it handles semicolons in if..then..else statements are in my humble opinion very inconsistent and so do the semicolons between arguments in procedure and function declarations.

For example, this is legal pascal:

if i < 10 then
  WriteLn ('Yep it is smaller')        // <-- no semicolon
else
  WriteLn ('Nope, sorry it is larger');

but adding a semicolon where you think it should go is actually illegal. the then keyword ofcourse also totally sucks, C-s braces are much more elegant.

Also parameters in procedure declarations:
To me a semicolon means 'end of statement', but here this
does not hold. Also the semicolon at the end of the signature
seems strange to me.

procedure DoSomething (i: integer; c: char);
begin
  WriteLn ('Something');
end;

But what *is* good about this is that it makes the signature exactly the same as the prototype, which really improves cut'n pastability. ;)

But what about the totally redundant difference between a function and a procedure? I like the way a C procedure is implemented as a function that returns void. It is much more elegant.

It might seem like I am trying to trash pascal, but actually I am really not. I often defend Delphi against C-minded friends, because I really love it. I particularly like things such as:

- properties, also in D
- published keyword
- sets
- method pointers, D has delegates
- no fall-through switch
- the Result variable
- the way units work, C's #include sucks to the bone!
  D essentially does the same as Pascal.
- the native string type
  D has arrays of chars which are capable of all
  important operations you might want to do on strings.

Now you know why I am so enthousiatic about D!  :)


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:ab97l5$25ee$1@digitaldaemon.com...
> "Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:ab92qn$213l$1@digitaldaemon.com...
> >
> > "Walter" <walter@digitalmars.com> wrote in message news:ab426p$310j$1@digitaldaemon.com...
> > >
> <SNIP>
> > >
> > > Yes, it is. But remember I came to C from Pascal (I actually wrote a mini-Pascal compiler once), and never looked back.
> >
> > Can you discuss why?  I am certainly not claiming that Pascal is "the perfect language", but IMHO, it is a better "starting point" for
> enhancement
> > toward that goal than is C.  See for example, the Turing language, which bears about the same resemblance to Pascal as D does to C. (that is,
> similar
> > syntax, but clean up a lot of the cruft and add some important
features.)
> >
>
> Pascal's syntax is actually one of the things I do not like about it. begin and end just get to be a pain in the you-know-where and do not really add much. The way it handles semicolons in if..then..else statements are in my humble opinion very inconsistent and so do the semicolons between arguments in procedure and function declarations.

Then you might really like Turing.  They eliminated the semicolons altogether and made the begin/end stuff consistant.

> the then keyword ofcourse also totally sucks, C-s
> braces are much more elegant.

Braces are an exact syntactical shortcut for begin/end in Turing.

snip

> But what about the totally redundant difference between a function and a procedure? I like the way a C procedure is implemented as a function that returns void. It is much more elegant.

Well, that is really just syntax difference.  Turing guarantees, (enforced at compile time) that functions (as opposed to procedures) have no side effects.  This eliminates a lot of aliasing problems that cause bugs and hurt performance.


>
> It might seem like I am trying to trash pascal, but actually I am really not. I often defend Delphi against C-minded friends, because I really love it. I particularly like things such as:
>
> - properties, also in D
> - published keyword
> - sets
> - method pointers, D has delegates
> - no fall-through switch
> - the Result variable
> - the way units work, C's #include sucks to the bone!
>   D essentially does the same as Pascal.
> - the native string type
>   D has arrays of chars which are capable of all
>   important operations you might want to do on strings.
>
> Now you know why I am so enthousiatic about D!  :)

I understand.  You might enjoy checking out Turing for comparison. Unfortunately, it isn't open source or free, but it is low cost and there are some docs available free.

--
 - Stephen Fuld
   e-mail address disguised to prevent spam

"OddesE" <OddesE_XYZ@hotmail.com> ha scritto nel messaggio news:ab97l5$25ee$1@digitaldaemon.com...
>
> Pascal's syntax is actually one of the things I do not like about it. begin and end just get to be a pain in the you-know-where and do not really add much. The way it handles semicolons in if..then..else statements are in my humble opinion very inconsistent and so do the semicolons between arguments in procedure and function declarations.
>
> For example, this is legal pascal:
>
> if i < 10 then
>   WriteLn ('Yep it is smaller')        // <-- no semicolon
> else
>   WriteLn ('Nope, sorry it is larger');
                                                       ^^^ semicolon is not
mandatory here
Curious, I think the same for C. In Pascal a block is a list of
instructions,
so you'll have: begin inst1 ; inst2 ; inst3 end. The same is for procedures
or functions arguments: ( arg1 ; arg2 ; arg3 ), you have the same in C with
the colon: ( arg1 , arg2 , arg3 ).
Instead It's difficult to say when in C there is a need for semicolon:

int f()
{
}  // <-- no semicolon

struct a
{
  ...
};  // <-- semicolon

int g()
{
    if (a < b)
        c = a;   // <-- semicolon
    else
    {
         c = d;
    }   // <-- no semicolon
    e = f; // <-- semicolon
}

> but adding a semicolon where you think it should go is actually illegal. the then keyword ofcourse also totally sucks, C-s braces are much more elegant.

Braces are more small. And Pascal was designed when not all computer keyboards had braces on it (mine still today has not).

[...]
> But what about the totally redundant difference between a function and a procedure? I like the way a C procedure is implemented as a function that returns void. It is much more elegant.

It seems more a trick... In original C there was no 'void' keyword, so no procedures at all. void was introduced to be more Pascal-like.

Ciao

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:ab6fii$2fg9$1@digitaldaemon.com...
> > > Needing casts for ordinary mundane operations means there's a bug in
the
> > > language design.
> > long *ptr;
> > .....
> > ptr = cast(long*)(cast(byte*)ptr +1 );   /* add one byte to the pointer
*/
> > Remember, adding one byte to a pointer is a mundane operation...but it
> requires
> > *2* casts.

I don't think that's an ordinary operation.


> I think this has been addressed before, but math on void* should be identical to math on byte*.  i.e.   void* p;  p += 2;  should move p
forward
> 2 bytes.

I'm ahead of you there, you can do arithmetic on void* as if they were byte pointers. This eliminates the misleading C eyesore of constant casting to (char*) when you are not accessing chars, but are doing pointer arithmetic.