Re: declaration/expression
> import tango.io.Stdout;
> void main(){
> int[4] i = [1,2,3,4];
> T(t); // compiler: I think this is an expression *barf* t(i[])(i[]);
> //compiler: I think this is a declaration *barf*
> }
>
> class T{
> public T opCall(int[] i){
> Stdout(i).newline;
> return this;
> }
> }
In your example are at least two errors.
T(t); -- the "t" is not defined there
public T opCall(int[] i) { -- it should be called as t(i), if you want
call T(i), make this method static.
I personally do not encounter problem you are writing about. But you
should be aware of: Expressions that have no effect, like (x + x), are
illegal in expression statements. If such an expression is needed,
casting it to void will make it legal.
http://www.digitalmars.com/d/1.0/statement.html#ExpressionStatement
The dmd compiler license
I don't know if this has been brought up before, but today I just happened to look at the text of the license that comes with dmd, The Software is not generally available software. It has not undergone testing and may contain errors. The Software was not designed to operate after December 31, 1999. It may be incomplete and it may not function properly. No support or maintenance is provided with this Software. Do not install or distribute the Software if you are not accustomed to using or distributing experimental software. Do not use this software for life critical applications, or applications that could cause significant harm or property damage. Well, with this kind of text, how can we *ever* expect D to be adopted?! It says right there: don't touch me, I'm dangerous. I'm talking specifically about this line right here: Do not install or distribute the Software if you are not accustomed to using or distributing experimental software.
Re: CloseHandle missing in phobos/std/file.dtrunk/phobos/std/file.d read?
On 23.06.2009 13:49, dennis luehring wrote: 151 scope(exit) cenforce(CloseHandle(h), name); sorry missed that line
CloseHandle missing in phobos/std/file.dtrunk/phobos/std/file.d read?
version(Windows) void[] read(in char[] name)
140 {
141 alias TypeTuple!(GENERIC_READ,
142 FILE_SHARE_READ, (SECURITY_ATTRIBUTES*).init,
OPEN_EXISTING,
143 FILE_ATTRIBUTE_NORMAL | FILE_FLAG_SEQUENTIAL_SCAN,
144 HANDLE.init)
145 defaults;
146 auto h = useWfuncs
147 ? CreateFileW(std.utf.toUTF16z(name), defaults)
148 : CreateFileA(toMBSz(name), defaults);
149
150 cenforce(h != INVALID_HANDLE_VALUE, name);
151 scope(exit) cenforce(CloseHandle(h), name);
152 const size = GetFileSize(h, null);
153 cenforce(size != INVALID_FILE_SIZE, name);
154 auto buf = GC.malloc(size, GC.BlkAttr.NO_SCAN)[0 .. size];
155 scope(failure) delete buf;
156
157 DWORD numread;
158 cenforce(ReadFile(h,buf.ptr, size, &numread, null) == 1
159 && numread == size, name);
160 return buf[0 .. size];
CloseHandle missing here?
161 }
Re: Making changes to Wiki4D
On Mon, 22 Jun 2009 22:30:36 -0700, Brad Roberts wrote: > I'm certainly willing to setup mediawiki for us. The responses on the > thread I started a while ago ranged from useless side-discussions to > luke warm to insulting. So I haven't done anything (that and I've been > on vacation out of town for the last 5 days). > > Want me to? I look to the main people who maintain the wiki for > guidance. Personally, I think it'd be an improvement, but I'm just one > among many. > > Later, > Brad Personally I don't see much difference from one wiki to another, I never try to do anything fancy with them. I should have the restructured site up by the end of the week, but it will still need more content cleanup.
Re: declaration/expression
On Tue, Jun 23, 2009 at 1:00 AM, Ellery Newcomer wrote: > Sorry for not posting this in learn, but I'd also like to hear the > Language Designer's input on this one. > > How does dmd resolve the declaration/expression ambiguity? > > My first instinct would be to try the declaration, and if it doesn't > work because the type doesn't exist or something like that then try the > expression, or vice versa. But that could easily lead to undefined and > unexpected behavior. what if both are valid? You're right; if a statement begins with an identifier, the compiler requires arbitrary lookahead to determine whether it's looking at an expression or a declaration. There's a good bit of duplicated code in DMD dedicated to parsing declarations. IIRC there's one version of the parsing that just returns whether or not it's "probably" a declaration, and another version that does the exact same thing but which actually builds the AST. Kind of icky. But that being said, I don't think there are actually any ambiguities in the grammar when it comes to this. Neither of the "problem" lines in your example code could possibly be interpreted as declarations, and I don't think I can come up with any actually ambiguous code.
Re: The dmd compiler license
On Tue, Jun 23, 2009 at 04:02:37AM -0600, hasen wrote: > Well, with this kind of text, how can we *ever* expect D to be adopted?! Virtually ALL licenses basically say the same thing. It is just legal CYA stuff. >From the GPL, for example: THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. (And it is surrounded by several lines of basically screaming "NOT MY PROBLEM IF IT SUCKS"). It's nothing to get worked up about. -- Adam D. Ruppe http://arsdnet.net
Re: The dmd compiler license
On Tue, 23 Jun 2009 12:27:31 -0400, Adam D. Ruppe wrote: On Tue, Jun 23, 2009 at 04:02:37AM -0600, hasen wrote: Well, with this kind of text, how can we *ever* expect D to be adopted?! Virtually ALL licenses basically say the same thing. It is just legal CYA stuff. From the GPL, for example: THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. (And it is surrounded by several lines of basically screaming "NOT MY PROBLEM IF IT SUCKS"). It's nothing to get worked up about. Also, the licence refers to DMD itself, not software generated by DMD (i.e. D programs)
Re: The dmd compiler license
hasen wrote: > Well, with this kind of text, how can we *ever* expect D to be adopted?! > > It says right there: don't touch me, I'm dangerous. > > I'm talking specifically about this line right here: > >> Do not install or distribute the Software if you are not accustomed >> to using or distributing experimental software. I'd be much more worried about these lines: >> It has not undergone testing >> The Software was not designed to operate after December 31, 1999. >> No support or maintenance is provided with this Software. Those are pretty direct statements about the state of the compiler. The rest is pretty vague; standard disclaimer stuff. -- Michiel Helvensteijn
Re: Making changes to Wiki4D
== Quote from Jesse Phillips (jessekphill...@gmail.com)'s article ... > Personally I don't see much difference from one wiki to another, I > never try to do anything fancy with them. I should have the > restructured site up by the end of the week, but it will still need > more content cleanup. Jesse, I'm curious whether you were going to set up redirects for the new pages as part of your reorganization efforts (e.g., "#REDIRECT ComingFrom/BASICVariants"). Here's an example of a redirected page: http://www.prowiki.org/wiki4d/wiki.cgi?edit=DocComments/StdBitarray
Re: Making changes to Wiki4D
Justin Calvarese Wrote: > Jesse, > > I'm curious whether you were going to set up redirects for the new > pages as part of your reorganization efforts (e.g., "#REDIRECT > ComingFrom/BASICVariants"). > > Here's an example of a redirected page: > http://www.prowiki.org/wiki4d/wiki.cgi?edit=DocComments/StdBitarray I would love to, thank you for the information on how to do that.
Re: Making changes to Wiki4D
Jesse Phillips wrote: > On Mon, 22 Jun 2009 22:30:36 -0700, Brad Roberts wrote: > >> I'm certainly willing to setup mediawiki for us. The responses on the >> thread I started a while ago ranged from useless side-discussions to >> luke warm to insulting. So I haven't done anything (that and I've been >> on vacation out of town for the last 5 days). >> >> Want me to? I look to the main people who maintain the wiki for >> guidance. Personally, I think it'd be an improvement, but I'm just one >> among many. >> >> Later, >> Brad > > Personally I don't see much difference from one wiki to another, I never > try to do anything fancy with them. I should have the restructured site > up by the end of the week, but it will still need more content cleanup. Ok.. then let's just leave things as they are. One request, would you work out how to make examining the history of a page work correctly? I never can seem to get anything other than the most recent change. Admittedly, I haven't tried in a while. That's one of the things about mediawiki I really like. Exploring the document history is _easy_. Thanks, Brad
Re: Making changes to Wiki4D
On 23.06.2009 22:05, Brad Roberts wrote: Ok.. then let's just leave things as they are. One request, would you work out how to make examining the history of a page work correctly? I never can seem to get anything other than the most recent change. Admittedly, I haven't tried in a while. That's one of the things about mediawiki I really like. Exploring the document history is _easy_. You problably want the link at the bottom called Archive.
Re: Suggestion: Syntactic sugar for Exception handling in D2
> If it's braces you're concerned with, D doesn't actually require them > on try/catch/finally like many other languages: As I said, the braces is just the small obvious benefit. The larger benefit IMHO is the less obvious shift in how you think about exceptions, but I'm not sure that argument is worth anything if you haven't experienced it personally. Writing braces is even done automatically by some editors, but thinking of exception handling as a natural part of a method (just like in/out contracts are part of the method, and unittests/invariants are a natural part of a class). It's about how the language encourages the developer to think about certain aspects, and that is of course almost impossible to really assess the value of.
Re: Suggestion: Syntactic sugar for Exception handling in D2
> I suggest looking at D's scope guard statements, which replace most uses > of try statements. While scope guards is absolutely the right solution to resource handling and transactions, I don't see how to use it for some other common uses of exceptions where you need a reference to the exception that was thrown such as error-logging, and exception wrapping. As I've written in a few other places in the thread now, it's not about lacking other solutions to the problem. Scope guards and the existing exception-handling do cover all possible cases. It's neither about fear of wearing out my bracket-keys. It's merely about readability, and slightly shifting how the language affect how developers think about exception handling, trying to make exception-cases a natural but separate part of each method (1). I think I'm already seeing that same reasoing for a few other features in D, such as the contract and unittest-constructs in the language. But those values are highly subjective, and how the language affect the mindset is also very difficult to assess and value without working with it for a while. 1) I've completely abandoned the idea for other blocks than methods. It was a bad idea from start, just ambiguous and doesn't make sense at all.
Re: declaration/expression
Jarrett Billingsley wrote: > On Tue, Jun 23, 2009 at 1:00 AM, Ellery > Newcomer wrote: >> Sorry for not posting this in learn, but I'd also like to hear the >> Language Designer's input on this one. >> >> How does dmd resolve the declaration/expression ambiguity? >> >> My first instinct would be to try the declaration, and if it doesn't >> work because the type doesn't exist or something like that then try the >> expression, or vice versa. But that could easily lead to undefined and >> unexpected behavior. what if both are valid? > > You're right; if a statement begins with an identifier, the compiler > requires arbitrary lookahead to determine whether it's looking at an > expression or a declaration. There's a good bit of duplicated code in > DMD dedicated to parsing declarations. IIRC there's one version of > the parsing that just returns whether or not it's "probably" a > declaration, and another version that does the exact same thing but > which actually builds the AST. Kind of icky. Heh. I saw that. I also saw a toExpression function in various declaration structs. Didn't look deeply into it though. > > But that being said, I don't think there are actually any ambiguities > in the grammar when it comes to this. Neither of the "problem" lines > in your example code could possibly be interpreted as declarations, > and I don't think I can come up with any actually ambiguous code. Wrong. Both are perfectly valid declarations (and did you miss my note? the compiler *IS* interpreting the second as a declaration). Okay, consider the rule declarator, which is (or should, if the grammar wants to correctly reflect what the compiler is doing) defined like so Declarator: BasicType2opt Identifier DeclaratorSuffixesopt BasicType2opt ( Declarator ) DeclaratorSuffixesopt This is what allows D to accept C-style (forgot about those, didn't ya?) declarations, and it's mostly what I'm referring to. Watch: int(i); //compiles exactly the same as 'int i;' int(*i)(int[]); //compiles the same as 'int function(int[]) i;' So when I give something like T(t); t(*i)(i[]); //changed it a little, since 'int (i[])(int[])' //is semantically invalid I intend a declaration and an expression. I get the opposite. Fortunately, neither compiles, due to semantic errors. To restate my question, if I'm a parser and I see Identifier ( Identifier ) ; which do I interpret it as? Type ( NewSymbol ) ; FunctionName ( Argument ) ; If I see Identifier . Identifier ( * Identifier ) ; what do I resolve it as? And it just goes downhill from there.
Re: declaration/expression
Hello Ellery, This is what allows D to accept C-style (forgot about those, didn't ya?) declarations, and it's mostly what I'm referring to. Watch: Yes and I now I even more wish DMD would to :(
Re: declaration/expression
On Tue, Jun 23, 2009 at 8:35 PM, Ellery Newcomer wrote: > Wrong. Both are perfectly valid declarations (and did you miss my note? > the compiler *IS* interpreting the second as a declaration). > Okay, consider the rule declarator, which is (or should, if the grammar > wants to correctly reflect what the compiler is doing) defined like so > > Declarator: > BasicType2opt Identifier DeclaratorSuffixesopt > BasicType2opt ( Declarator ) DeclaratorSuffixesopt Ah, fuck. I can't believe D still accepts those. All the ambiguity probably goes away without them, huh.
Re: The dmd compiler license
Michiel Helvensteijn wrote: > I'd be much more worried about these lines: > >>> It has not undergone testing Walter has a test suite for DMD, and there's the huge one on (I think) puremagic. >>> The Software was not designed to operate after December 31, 1999. OH NO! All our programs will stop compiling on Jan 1 2000... wait... >>> No support or maintenance is provided with this Software. I think the existence of these forums and the bugtracker says otherwise. > Those are pretty direct statements about the state of the compiler. The rest > is pretty vague; standard disclaimer stuff. No, I think they are also of a "you can't sue me if it asplodes" nature.
Re: declaration/expression
Ellery Newcomer wrote: To restate my question, if I'm a parser and I see Identifier ( Identifier ) ; which do I interpret it as? Type ( NewSymbol ) ; FunctionName ( Argument ) ; After some incremental parsing iterations you should be able to gradually resolve dependencies for each expression. If it's not ambiguous on what the source is trying to describe and all its dependencies are resolved then you add the new types that it may be declaring to a collection of parsed types. Repeat until everything can be passed and eventually you should know exactly what the first ID is (type, func etc). IIRC opCall can not be declared static. Sorry if I am completely missing the point but this doesn't seem complex (in a problem solving sense but the code writing may be tedious)
