www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: Minor extension to cast syntax

reply Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Gregor Richards Wrote:


 Blech. Makes it look like you're calling a function with arguments being 
 a type and then some expression. The current syntax is more similar to 
 calling a templated cast function:
 
 cast(int)(foo)
 cast!(int)(foo)
 
 That is, cast is a function with a template parameter of the type you're 
 casting it to. This isn't how it's implemented at all of course, but the 
 syntax is reminiscent of that, and I think that's the better analogy.
 
   - Gregor Richards



Surely a cast is really a kind of function opCast() so using function syntax is
appropriate. The old syntax sticks out as unusual. There is that idea in
language design that if it can be done as a function it should be unless there
is a good reason not to. So, having inherited the C like syntax was their ever
a good reason for it? does that reason still apply? If you were starting over
again (as was supposed to be the case with D) would you still do it this way?

Regards,

Bruce.
Oct 31 2007
parent reply Gregor Richards <Richards codu.org> writes:
Bruce Adams wrote:

 Gregor Richards Wrote:
 

 Blech. Makes it look like you're calling a function with arguments being 
 a type and then some expression. The current syntax is more similar to 
 calling a templated cast function:

 cast(int)(foo)
 cast!(int)(foo)

 That is, cast is a function with a template parameter of the type you're 
 casting it to. This isn't how it's implemented at all of course, but the 
 syntax is reminiscent of that, and I think that's the better analogy.

   - Gregor Richards



 Surely a cast is really a kind of function opCast() so using function syntax
is appropriate.



My point was not the function syntax, my point was that it was a 
function that takes a type as an argument. That makes no sense.


 The old syntax sticks out as unusual.



Good. Casting is an unusual operation.


 There is that idea in language design that if it can be done as a function it
should be unless there is a good reason not to.



In highly dynamic languages where performance isn't a primary objective, 
yes. Dynamic arrays, anyone?


 So, having inherited the C like syntax was their ever a good reason for it?



Yes. casting is a procedure which is not similar to anything else in C, 
so it has its own syntax.


 does that reason still apply?



Yes, casting is a procedure which is not similar to anything else in D, 
so it has its own syntax.



 If you were starting over again (as was supposed to be the case with D) would
you still do it this way?



I write dynamic languages :)


 
 Regards,
 
 Bruce.
 



  - Gregor Richards
Oct 31 2007
parent reply Gregor Richards <Richards codu.org> writes:
Gregor Richards wrote:

 There is that idea in language design that if it can be done as a 
 function it should be unless there is a good reason not to.



 In highly dynamic languages where performance isn't a primary objective, 
 yes. Dynamic arrays, anyone?
 



I should also mention, while I'm at it, that this can NOT be done as a 
function.

  - Gregor Richards
Oct 31 2007
next sibling parent reply Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Gregor Richards Wrote:


 Gregor Richards wrote:

 There is that idea in language design that if it can be done as a 
 function it should be unless there is a good reason not to.



 In highly dynamic languages where performance isn't a primary objective, 
 yes. Dynamic arrays, anyone?
 



 I should also mention, while I'm at it, that this can NOT be done as a 
 function.
 
   - Gregor Richards



It could if your language was dynamic enough to support types as first class
objects so that no meta syntax was required. :)
Oct 31 2007
next sibling parent reply Gregor Richards <Richards codu.org> writes:
Bruce Adams wrote:

 Gregor Richards Wrote:
 

 Gregor Richards wrote:

 There is that idea in language design that if it can be done as a 
 function it should be unless there is a good reason not to.



 yes. Dynamic arrays, anyone?



 function.

   - Gregor Richards



 It could if your language was dynamic enough to support types as first class
objects so that no meta syntax was required. :)
 



Yeah, but that's a matter of goals ... I love dynamic languages, my pet 
language is entirely prototype-based, so "types" are really just 
prototype objects, and are therefore passable like any other object. It 
makes things like generics really easy and intuitive, and of course 
casting is just one comparison away :)

But D is a static language, and has different goals.

  - Gregor Richards
Oct 31 2007
parent reply Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Gregor Richards Wrote:


 Bruce Adams wrote:

 Gregor Richards Wrote:
 

 Gregor Richards wrote:

 There is that idea in language design that if it can be done as a 
 function it should be unless there is a good reason not to.



 yes. Dynamic arrays, anyone?



 function.

   - Gregor Richards



 It could if your language was dynamic enough to support types as first class
objects so that no meta syntax was required. :)
 



 Yeah, but that's a matter of goals ... I love dynamic languages, my pet 
 language is entirely prototype-based, so "types" are really just 
 prototype objects, and are therefore passable like any other object. It 
 makes things like generics really easy and intuitive, and of course 
 casting is just one comparison away :)
 
 But D is a static language, and has different goals.
 
   - Gregor Richards



Agreed but wouldn't it be nice to find a language with the best of both world?
By the way, which is your pet language.

Regards,

Bruce.
Oct 31 2007
parent Gregor Richards <Richards codu.org> writes:
Bruce Adams wrote:

 Gregor Richards Wrote:
 

 Bruce Adams wrote:

 Gregor Richards Wrote:


 Gregor Richards wrote:

 There is that idea in language design that if it can be done as a 
 function it should be unless there is a good reason not to.



 yes. Dynamic arrays, anyone?



 function.

   - Gregor Richards






 language is entirely prototype-based, so "types" are really just 
 prototype objects, and are therefore passable like any other object. It 
 makes things like generics really easy and intuitive, and of course 
 casting is just one comparison away :)

 But D is a static language, and has different goals.

   - Gregor Richards



 Agreed but wouldn't it be nice to find a language with the best of both world?
By the way, which is your pet language.
 
 Regards,
 
 Bruce.



A little language I call "Plof". http://www.codu.org/plof/

Plof2 is the current incarnation, which (as with Plof1) is giving way to 
Plof3 :P ... suffice to say that Plof isn't really a usable language 
yet, I mainly use it as an environment for playing with language design.

  - Gregor Richards
Oct 31 2007
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Bruce Adams wrote:

 Gregor Richards Wrote:
 

 Gregor Richards wrote:

 There is that idea in language design that if it can be done as a 
 function it should be unless there is a good reason not to.



 yes. Dynamic arrays, anyone?



 function.

   - Gregor Richards



 It could if your language was dynamic enough to support types as first class
objects so that no meta syntax was required. :)
 



D could very well allow types as function parameters, and that wouldn't 
require any particular dynamicness or anything like that to the 
language. It would just a be a uniformization of function and template 
syntax for invocation and declaration, and, if done well, it could be a 
very cool addition (especially with the coming of AST macros). We have 
already some advances in this, like CTFE. Indeed, templates are really 
just compile time functions, which are also able to take some 
compile-time only constructs (such as types, aliases, etc.).



-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Nov 03 2007
prev sibling parent BCS <BCS pathlink.com> writes:
Gregor Richards wrote:

 Gregor Richards wrote:
 

 There is that idea in language design that if it can be done as a 
 function it should be unless there is a good reason not to.




 In highly dynamic languages where performance isn't a primary 
 objective, yes. Dynamic arrays, anyone?



 I should also mention, while I'm at it, that this can NOT be done as a 
 function.
 
  - Gregor Richards




you sort of can. Allow static virtual member function
and then let types (including built in's) define
opCastFrom's Then this

cast(T)(r);

gets rewritten as this

T.opCastFrom(r);

where the T is a "runtime Type variable" that is in
fact just a v-tbl pointer.

Except for the static virtual member functions, if any
of that gets implemented I will fly out to Seattle and
throw new WetSpaghetti();// at Walter.
Oct 31 2007