digitalmars.D - Shared with no type in Druntime.
- Adam Wilson (29/29) Apr 28 2012 Ok. So i've been trying to build Phobos with my new DI generation code
- =?UTF-8?B?QWxpIMOHZWhyZWxp?= (17/40) Apr 28 2012 Yes. D does type inference all the time. Most of the time 'auto' is used...
- Adam Wilson (28/76) Apr 28 2012 e
- Jonathan M Davis (15/24) Apr 28 2012 There's nothing sloppy about it whatsoever. If you think that that's slo...
- Adam Wilson (18/51) Apr 28 2012 Ok, I can accept that. Explicit typing is lots of extra pointless typing...
- Paulo Pinto (7/55) Apr 29 2012 Maybe I have been spoiled by doing too much programming in languages
- Jacob Carlborg (11/21) Apr 29 2012 No, I think it's way better that the DI generator outputs the actually
- Jakob Ovrum (3/11) Apr 29 2012 I agree, except to get the right behaviour, I think that must be:
- Adam Wilson (23/43) Apr 30 2012 I agree, however, DMD has not yet performed it's semantic analysis at th...
- Jacob Carlborg (6/22) May 01 2012 Ok, I didn't know about this. Regardless I think this needs to be solved...
Ok. So i've been trying to build Phobos with my new DI generation code (available here: https://github.com/LightBender/dmd.git) and i've run into an interesting usage of shared in the D Runtime. Namely, it has no type. I've been told that this is not correct and it should have a type. Is that correct? Currently the source file (stdio.d in the DRT) has this in it and it compiles successfully: private extern shared FILE[_NFILE] _iob; shared stdin = &_iob[0]; shared stdout = &_iob[1]; shared stderr = &_iob[2]; shared stdaux = &_iob[3]; shared stdprn = &_iob[4]; With the new DI generation code stdio.di contains this: private extern shared FILE[_NFILE] _iob; shared stdin; (Errors here and all subsequent lines in this snippet) shared stdout; shared stderr; shared stdaux; shared stdprn; Is D doing some kind of type inference based on the type of the _iob variable in the first example that causes DMD to throw an error with the "= &_iob[0];" part removed? -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Apr 28 2012
On 04/28/2012 06:08 PM, Adam Wilson wrote:Ok. So i've been trying to build Phobos with my new DI generation code (available here: https://github.com/LightBender/dmd.git) and i've run into an interesting usage of shared in the D Runtime. Namely, it has no type. I've been told that this is not correct and it should have a type. Is that correct? Currently the source file (stdio.d in the DRT) has this in it and it compiles successfully: private extern shared FILE[_NFILE] _iob; shared stdin = &_iob[0]; shared stdout = &_iob[1]; shared stderr = &_iob[2]; shared stdaux = &_iob[3]; shared stdprn = &_iob[4]; With the new DI generation code stdio.di contains this: private extern shared FILE[_NFILE] _iob; shared stdin; (Errors here and all subsequent lines in this snippet) shared stdout; shared stderr; shared stdaux; shared stdprn; Is D doing some kind of type inference based on the type of the _iob variable in the first example that causes DMD to throw an error with the "= &_iob[0];" part removed?Yes. D does type inference all the time. Most of the time 'auto' is used because most variables have automatic storage class. The following are all legal: void main() { auto a = 42; // int const c = "hello"; // string immutable i = 1.5; // double struct S {} shared s = new shared(S); // S* enum e = [ 0, 1 ]; // int[] } All of the standard streams are of type File: assert(typeid(stdin) == typeid(std.stdio.File)); Ali
Apr 28 2012
On Sat, 28 Apr 2012 18:23:30 -0700, Ali =C7ehreli <acehreli yahoo.com> w= rote:On 04/28/2012 06:08 PM, Adam Wilson wrote:eOk. So i've been trying to build Phobos with my new DI generation cod=(available here: https://github.com/LightBender/dmd.git) and i've run=nointo an interesting usage of shared in the D Runtime. Namely, it has =pe.type. I've been told that this is not correct and it should have a ty=theIs that correct? Currently the source file (stdio.d in the DRT) has this in it and it compiles successfully: private extern shared FILE[_NFILE] _iob; shared stdin =3D &_iob[0]; shared stdout =3D &_iob[1]; shared stderr =3D &_iob[2]; shared stdaux =3D &_iob[3]; shared stdprn =3D &_iob[4]; With the new DI generation code stdio.di contains this: private extern shared FILE[_NFILE] _iob; shared stdin; (Errors here and all subsequent lines in this snippet) shared stdout; shared stderr; shared stdaux; shared stdprn; Is D doing some kind of type inference based on the type of the _iob variable in the first example that causes DMD to throw an error with =ed ="=3D &_iob[0];" part removed?Yes. D does type inference all the time. Most of the time 'auto' is us=because most variables have automatic storage class. The following are==all legal: void main() { auto a =3D 42; // int const c =3D "hello"; // string immutable i =3D 1.5; // double struct S {} shared s =3D new shared(S); // S* enum e =3D [ 0, 1 ]; // int[] } All of the standard streams are of type File: assert(typeid(stdin) =3D=3D typeid(std.stdio.File)); AliOk, so that answers the legality of the issue, but it smacks of sloppy = coding. We cannot ship the DRT as a dynamic library, as has been discuss= ed = and agreed to as a good idea, if their are variable declarations that re= ly = on type inference from an assignment operation because those assignments= = will get stripped out of the DI. So what should I do then? Because share= d = stdin; by itself with no assignment to infer from IS illegal and there i= s = not (that I can see) a way to separate an instantiation from an = implementation and the whole point of DI files is too remove = implementations. -- = Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Apr 28 2012
On Saturday, April 28, 2012 18:32:00 Adam Wilson wrote:Ok, so that answers the legality of the issue, but it smacks of sloppy coding. We cannot ship the DRT as a dynamic library, as has been discussed and agreed to as a good idea, if their are variable declarations that rely on type inference from an assignment operation because those assignments will get stripped out of the DI. So what should I do then? Because shared stdin; by itself with no assignment to infer from IS illegal and there is not (that I can see) a way to separate an instantiation from an implementation and the whole point of DI files is too remove implementations.There's nothing sloppy about it whatsoever. If you think that that's sloppy coding, then you're going to think that auto is sloppy coding, and you're going to be very unhappy with a lot of D code. Taking advantage of such type inference is considered _good_ style in D. For the most part, you shouldn't use the type explicitly unless you actually need to. If you need to put a variable in a .di file without its initializer, then that's a case where you're going to need to use the type explicitly. That means that either the .di generator is going to leave the initializer in (which I expect is what it currently does) - in which case you'd need to change it by hand - or it's going to need to take the type of the initializer and use that in the variable's declaration in the .di file rather than using shared by itself or auto or whatever it was using that involved type inference. - Jonathan M Davis
Apr 28 2012
On Sat, 28 Apr 2012 19:23:28 -0700, Jonathan M Davis <jmdavisProg gmx.com> wrote:On Saturday, April 28, 2012 18:32:00 Adam Wilson wrote:Ok, I can accept that. Explicit typing is lots of extra pointless typing when the compiler can just figure it out for me. But that leaves us with an interesting design question. Right now, DI gen is destructive, which means any changes I make to the DI file will get destroyed on the next build if I forget to remove the -H flags. Unfortunately that means that the DI generator is going to have to somewhat dictate coding style and we need to make sure that DI gen covers the broadest possible range of potential uses. Personally, I have no problem leaving in initializers for module level variables. Is that an acceptable solution to the community? -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/Ok, so that answers the legality of the issue, but it smacks of sloppy coding. We cannot ship the DRT as a dynamic library, as has been discussed and agreed to as a good idea, if their are variable declarations that rely on type inference from an assignment operation because those assignments will get stripped out of the DI. So what should I do then? Because shared stdin; by itself with no assignment to infer from IS illegal and there is not (that I can see) a way to separate an instantiation from an implementation and the whole point of DI files is too remove implementations.There's nothing sloppy about it whatsoever. If you think that that's sloppy coding, then you're going to think that auto is sloppy coding, and you're going to be very unhappy with a lot of D code. Taking advantage of such type inference is considered _good_ style in D. For the most part, you shouldn't use the type explicitly unless you actually need to. If you need to put a variable in a .di file without its initializer, then that's a case where you're going to need to use the type explicitly. That means that either the .di generator is going to leave the initializer in (which I expect is what it currently does) - in which case you'd need to change it by hand - or it's going to need to take the type of the initializer and use that in the variable's declaration in the .di file rather than using shared by itself or auto or whatever it was using that involved type inference. - Jonathan M Davis
Apr 28 2012
Am 29.04.2012 05:03, schrieb Adam Wilson:On Sat, 28 Apr 2012 19:23:28 -0700, Jonathan M Davis <jmdavisProg gmx.com> wrote:Maybe I have been spoiled by doing too much programming in languages that have module systems, but why is the initialization shown in the .di file? This is an implementation issue on the module. -- PauloOn Saturday, April 28, 2012 18:32:00 Adam Wilson wrote:Ok, I can accept that. Explicit typing is lots of extra pointless typing when the compiler can just figure it out for me. But that leaves us with an interesting design question. Right now, DI gen is destructive, which means any changes I make to the DI file will get destroyed on the next build if I forget to remove the -H flags. Unfortunately that means that the DI generator is going to have to somewhat dictate coding style and we need to make sure that DI gen covers the broadest possible range of potential uses. Personally, I have no problem leaving in initializers for module level variables. Is that an acceptable solution to the community?Ok, so that answers the legality of the issue, but it smacks of sloppy coding. We cannot ship the DRT as a dynamic library, as has been discussed and agreed to as a good idea, if their are variable declarations that rely on type inference from an assignment operation because those assignments will get stripped out of the DI. So what should I do then? Because shared stdin; by itself with no assignment to infer from IS illegal and there is not (that I can see) a way to separate an instantiation from an implementation and the whole point of DI files is too remove implementations.There's nothing sloppy about it whatsoever. If you think that that's sloppy coding, then you're going to think that auto is sloppy coding, and you're going to be very unhappy with a lot of D code. Taking advantage of such type inference is considered _good_ style in D. For the most part, you shouldn't use the type explicitly unless you actually need to. If you need to put a variable in a .di file without its initializer, then that's a case where you're going to need to use the type explicitly. That means that either the .di generator is going to leave the initializer in (which I expect is what it currently does) - in which case you'd need to change it by hand - or it's going to need to take the type of the initializer and use that in the variable's declaration in the .di file rather than using shared by itself or auto or whatever it was using that involved type inference. - Jonathan M Davis
Apr 29 2012
On 2012-04-29 05:03, Adam Wilson wrote:Ok, I can accept that. Explicit typing is lots of extra pointless typing when the compiler can just figure it out for me. But that leaves us with an interesting design question. Right now, DI gen is destructive, which means any changes I make to the DI file will get destroyed on the next build if I forget to remove the -H flags. Unfortunately that means that the DI generator is going to have to somewhat dictate coding style and we need to make sure that DI gen covers the broadest possible range of potential uses. Personally, I have no problem leaving in initializers for module level variables. Is that an acceptable solution to the community?No, I think it's way better that the DI generator outputs the actually type instead of just "shared/auto" and the assignment. In this case: shared stdin = &_iob[0]; Should be generated as: shared File stdin; Anything to the right of the assignment operator is just an implementation detail. -- /Jacob Carlborg
Apr 29 2012
On Sunday, 29 April 2012 at 15:21:10 UTC, Jacob Carlborg wrote:No, I think it's way better that the DI generator outputs the actually type instead of just "shared/auto" and the assignment. In this case: shared stdin = &_iob[0]; Should be generated as: shared File stdin; Anything to the right of the assignment operator is just an implementation detail.I agree, except to get the right behaviour, I think that must be: extern shared File stdin;
Apr 29 2012
On Sun, 29 Apr 2012 08:21:10 -0700, Jacob Carlborg <doob me.com> wrote:On 2012-04-29 05:03, Adam Wilson wrote:I agree, however, DMD has not yet performed it's semantic analysis at the time of DI generation so I have no clue what the type is when the files are generated. Theoretically that could be changed but such a decision is WAY above my paygrade and would probably require significant rewrites of the DI generation code, as in tearing it down and starting over. My understanding is that the reason for this is that the semantic analysis does significant rewriting of the AST and would probably drastically alter the look and even function of the output code... Also, there is this comment in the code to start the DI generation: /* Generate 'header' import files. * Since 'header' import files must be independent of command * line switches and what else is imported, they are generated * before any semantic analysis. */ My guess is that that has to do with the way the command-line switches impact the semantic analysis. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/Ok, I can accept that. Explicit typing is lots of extra pointless typing when the compiler can just figure it out for me. But that leaves us with an interesting design question. Right now, DI gen is destructive, which means any changes I make to the DI file will get destroyed on the next build if I forget to remove the -H flags. Unfortunately that means that the DI generator is going to have to somewhat dictate coding style and we need to make sure that DI gen covers the broadest possible range of potential uses. Personally, I have no problem leaving in initializers for module level variables. Is that an acceptable solution to the community?No, I think it's way better that the DI generator outputs the actually type instead of just "shared/auto" and the assignment. In this case: shared stdin = &_iob[0]; Should be generated as: shared File stdin; Anything to the right of the assignment operator is just an implementation detail.
Apr 30 2012
On 2012-04-30 20:21, Adam Wilson wrote:I agree, however, DMD has not yet performed it's semantic analysis at the time of DI generation so I have no clue what the type is when the files are generated. Theoretically that could be changed but such a decision is WAY above my paygrade and would probably require significant rewrites of the DI generation code, as in tearing it down and starting over. My understanding is that the reason for this is that the semantic analysis does significant rewriting of the AST and would probably drastically alter the look and even function of the output code... Also, there is this comment in the code to start the DI generation: /* Generate 'header' import files. * Since 'header' import files must be independent of command * line switches and what else is imported, they are generated * before any semantic analysis. */ My guess is that that has to do with the way the command-line switches impact the semantic analysis.Ok, I didn't know about this. Regardless I think this needs to be solved in the end. Perhaps a new semantic analysis phase that is only run when generating DI files. But that would probably be quite hard. -- /Jacob Carlborg
May 01 2012