Re: Plot2kill 0.2
On Sat, 05 Mar 2011 13:31:22 -0500, dsimcha wrote: On 3/5/2011 1:27 PM, Lars T. Kyllingstad wrote: Does this mean that it can save to vector formats now, or just that you intend to add that functionality? EPS would be awesome, because it's pretty much the only thing you can use directly with LaTeX. (Yes, pdfLaTeX accepts many other formats, but many scientific journals still require you to provide EPS figures.) Of course, one can usually convert losslessly between the various vector formats, but it would be most convenient if Plot2kill could save directly to EPS, PDF and SVG. -Lars ? Plot2kill (the GTK version) has been able to save to EPS, SVG, PDF, PNG, JPEG and BMP since I switched the GTK port to use the Cairo backend last July. (The DFL port can only do BMP and PNG.) If this is a killer feature for you, I apologize for not publicizing it more back then. I've been eating my own dogfood since then. All of the graphs in my Ph.D. proposal and a publication manuscript I'm working on are Plot2Kill rendered and saved in vector formats. Oh, I didn't know that. That's very cool! I can't remember seeing an announcement of this feature from you, nor did I expect the feature to be there, so I guess I just didn't look that closely for it. :) -Lars
LIFO refrigerators
Daniel Gibson napisał: You'd need a fridge with two doors: one in the front, one in the back. Insert new food in the front, get food to eat from the back (or the other way round). But reinsert opened food in the back (or, in the alternative case, in the front). Or a cylinder-shaped refrigerator with rotating food shelves. Put new stuff in the front and turn the shelf slightly clockwise to expose oldest food for eating. Ain't circular buffers yummy? -- Tomek (the patent holder ;-)
Re: Proposal for std.path replacement
Looks good overall. I have a few comments and nitpicks though: basename(dir/subdir/) -- subdir directory(dir/subdir/) -- dir Is this what everybody expects? I'm not sure, but another possibility would be to treat these as if dir/subdir/. is passed. What is the result of directory(/) or directory(d:/)? extension(file) -- extension(file.ext) -- ext What about file.? I tried it on NTFS, but trailing '.' seems to always be cut off. Is it possible to create such a file on unix systems? If yes, you won't be able to recreate it from the result of basename() and extension(). What about network shares like \\server\share\dir\file? Maybe it should also be shown in the examples? Does the \\server part need special consideration? Rainer Lars T. Kyllingstad wrote: As mentioned in the std.path.getName(): Screwy by design? thread, I started working on a rewrite of std.path a long time ago, but I got sidetracked by other things. The recent discussion got me working on it again, and it turned out there wasn't that much left to be done. So here it is, please comment: http://kyllingen.net/code/ltk/doc/path.html https://github.com/kyllingstad/ltk/blob/master/ltk/path.d Features: - Most functions work with all string types, i.e. all permutations of mutable/const/immutable(char/wchar/dchar)[]. Notable exceptions are toAbsolute() and toCanonical, because they rely on std.file.getcwd() which returns an immutable(char)[]. - Correct behaviour in corner cases that aren't covered by the current std.path. See the other thread for some examples, or take a look at the unittests for a more complete picture. - Saner naming scheme. (Still not set in stone, of course.) -Lars
Re: Proposal for std.path replacement
On Sunday 06 March 2011 00:37:15 Rainer Schuetze wrote: Looks good overall. I have a few comments and nitpicks though: basename(dir/subdir/) -- subdir directory(dir/subdir/) -- dir Is this what everybody expects? I'm not sure, but another possibility would be to treat these as if dir/subdir/. is passed. What is the result of directory(/) or directory(d:/)? How about baseName(dir/subdir/) -- subdir/ dirName(dir/subdir/) -- dir There _are_ programs (such as rsync) which care about whether a / is included at the end of the path. Doing that should also deal with the / and d:/ issue. So, I can see why Lars would have made the base name of dir/subdir be subdir instead of subdir/ (I don't know whether that's the current behavior or not, so he may just have copied it from what's currently there), but It seems to me that it will be more consistent to truet subdir/ as the base name of dir/subdir. Unfortunately, sometimes there _is_ a difference between subdir and subdir/. extension(file) -- extension(file.ext) -- ext What about file.? I tried it on NTFS, but trailing '.' seems to always be cut off. Is it possible to create such a file on unix systems? If yes, you won't be able to recreate it from the result of basename() and extension(). *nix doesn't really do anything special with any file names. The closest is files which start with . - most programs consider those to be hidden and don't show them. There's definitely no problem with using file. as a file name. This is probably a good argument for putting the . back in the extension like it was before. What about network shares like \\server\share\dir\file? Maybe it should also be shown in the examples? Does the \\server part need special consideration? Probably, unfortunately. \\ is kind of like a drive letter, so it really should be special cased, I think. - Jonathan M Davis
Re: Proposal for std.path replacement
On Thursday 03 March 2011 08:29:00 Lars T. Kyllingstad wrote: As mentioned in the std.path.getName(): Screwy by design? thread, I started working on a rewrite of std.path a long time ago, but I got sidetracked by other things. The recent discussion got me working on it again, and it turned out there wasn't that much left to be done. So here it is, please comment: http://kyllingen.net/code/ltk/doc/path.html https://github.com/kyllingstad/ltk/blob/master/ltk/path.d Features: - Most functions work with all string types, i.e. all permutations of mutable/const/immutable(char/wchar/dchar)[]. Notable exceptions are toAbsolute() and toCanonical, because they rely on std.file.getcwd() which returns an immutable(char)[]. - Correct behaviour in corner cases that aren't covered by the current std.path. See the other thread for some examples, or take a look at the unittests for a more complete picture. - Saner naming scheme. (Still not set in stone, of course.) I hate to be nitpicky, but I notice that you're the only author listed for this module. The current std.path has several authors - none of which are you. So, unless you rewrote all of the code from scratch (which you may have done), you really should put the other names on it too (though if you rewrote it thoroughly enough, they may have very little left in it that they did; unfortunately, without knowing who wrote what, you need to put all of their names on it if any of the original code is there). - Jonathan M Davis
Naming convention in Phobos
Okay, so there's a discussion about identifier names in the proposed std.path replacement -- should they be abbreviated or not? Should we perhaps seek to have a consistent naming convention for all identifier names in Phobos? Some of the potential benefits: Legibility, understandability and clarity (reduce ambiguity). Ease in finding a suitable function/class by name. Knowing if it's a cheap or costly function call. Aesthetics and professional appearance. Some properties that I can think of for discussion: Abbreviation (and if so, what to abbreviate and how much)? Preference of commonly used terms in other languages, contexts? Use of get and set prefixes or not (getName() or simply name())? Explicit use of a prefix (example: calc or calculate) for costly operations? Naming of function and template arguments? Uppercase, lowercase, camelcase, underscore in multi-word names? All caps for constants, or different appearance for different types (types, functions, arguments, constants...). What about acronyms: TCP, Tcp? Are there other concerns?
Re: Proposal for std.path replacement
On Sun, 06 Mar 2011 01:21:56 -0800, Jonathan M Davis wrote: On Thursday 03 March 2011 08:29:00 Lars T. Kyllingstad wrote: As mentioned in the std.path.getName(): Screwy by design? thread, I started working on a rewrite of std.path a long time ago, but I got sidetracked by other things. The recent discussion got me working on it again, and it turned out there wasn't that much left to be done. So here it is, please comment: http://kyllingen.net/code/ltk/doc/path.html https://github.com/kyllingstad/ltk/blob/master/ltk/path.d Features: - Most functions work with all string types, i.e. all permutations of mutable/const/immutable(char/wchar/dchar)[]. Notable exceptions are toAbsolute() and toCanonical, because they rely on std.file.getcwd() which returns an immutable(char)[]. - Correct behaviour in corner cases that aren't covered by the current std.path. See the other thread for some examples, or take a look at the unittests for a more complete picture. - Saner naming scheme. (Still not set in stone, of course.) I hate to be nitpicky, but I notice that you're the only author listed for this module. The current std.path has several authors - none of which are you. So, unless you rewrote all of the code from scratch (which you may have done), you really should put the other names on it too (though if you rewrote it thoroughly enough, they may have very little left in it that they did; unfortunately, without knowing who wrote what, you need to put all of their names on it if any of the original code is there). Everything you see in that module is completely rewritten from scratch. I started out by trying to make changes to the original std.path, but quickly found that I had to change so much it was better to start with a clean slate. As long as the module is a part of my own library, and doesn't contain anyone else's code, I'll only put my name on it. When it gets included in Phobos, and I add the remaining functions (fcmp, fnmatch, fncharmatch and expandTilde), I will of course be sure to list all authors. -Lars
Re: Naming convention in Phobos
On Sunday 06 March 2011 02:59:25 Jim wrote: Okay, so there's a discussion about identifier names in the proposed std.path replacement -- should they be abbreviated or not? Should we perhaps seek to have a consistent naming convention for all identifier names in Phobos? Some of the potential benefits: Legibility, understandability and clarity (reduce ambiguity). Ease in finding a suitable function/class by name. Knowing if it's a cheap or costly function call. Aesthetics and professional appearance. Some properties that I can think of for discussion: Abbreviation (and if so, what to abbreviate and how much)? Preference of commonly used terms in other languages, contexts? Use of get and set prefixes or not (getName() or simply name())? Explicit use of a prefix (example: calc or calculate) for costly operations? Naming of function and template arguments? Uppercase, lowercase, camelcase, underscore in multi-word names? All caps for constants, or different appearance for different types (types, functions, arguments, constants...). What about acronyms: TCP, Tcp? Are there other concerns? The general naming convention as far as variable names go is camelcased with the name starting with a lower case letter - this includes constants. Most of Phobos follows this, and the parts that haven't been have been moving towards it. There are likely to be a few exceptions, but on the whole, that's how it's supposed to be. Type names are the same, except they start with an upper case letter (this includes enum names - the enum values are capitalized the same as any other variables however). That's the way it has been, and that's the way that it's pretty much guaranteed to stay. Generally speaking, we want descriptive names, and I think that it's safe to say that we don't want overly long names, so if we can have descriptive but short names, that's generally best. get and set prefixes are likely to be rare, because most of such functions will be properties, and properties will normally have nouns for names and won't use get or set, but I don't think that we want to say that we'll _never_ have function names prefixed with get or set. Normally, we won't, but it's going to be very situation-dependent. Now, as for the rest of it, I don't really want to get into a big discussion of the best way to name everything. It's far too context-dependent and very quickly turns towards bike shedding. I think that it's appropriate for anyone who's developing a module for Phobos to come up with names that they think are reasonable and which follow the very basic naming conventions that we follow, and then have names adjusted as needed during the review process. I really don't think that we're going to get much of value by having a big discussion over general naming conventions. It seems to me like it's just going to be a classic situation for bike shedding and generally useless discussion. What we've been doing generally works just fine. - Jonathan M Davis
Re: Proposal for std.path replacement
On Sunday 06 March 2011 03:36:50 Lars T. Kyllingstad wrote: On Sun, 06 Mar 2011 01:21:56 -0800, Jonathan M Davis wrote: On Thursday 03 March 2011 08:29:00 Lars T. Kyllingstad wrote: As mentioned in the std.path.getName(): Screwy by design? thread, I started working on a rewrite of std.path a long time ago, but I got sidetracked by other things. The recent discussion got me working on it again, and it turned out there wasn't that much left to be done. So here it is, please comment: http://kyllingen.net/code/ltk/doc/path.html https://github.com/kyllingstad/ltk/blob/master/ltk/path.d Features: - Most functions work with all string types, i.e. all permutations of mutable/const/immutable(char/wchar/dchar)[]. Notable exceptions are toAbsolute() and toCanonical, because they rely on std.file.getcwd() which returns an immutable(char)[]. - Correct behaviour in corner cases that aren't covered by the current std.path. See the other thread for some examples, or take a look at the unittests for a more complete picture. - Saner naming scheme. (Still not set in stone, of course.) I hate to be nitpicky, but I notice that you're the only author listed for this module. The current std.path has several authors - none of which are you. So, unless you rewrote all of the code from scratch (which you may have done), you really should put the other names on it too (though if you rewrote it thoroughly enough, they may have very little left in it that they did; unfortunately, without knowing who wrote what, you need to put all of their names on it if any of the original code is there). Everything you see in that module is completely rewritten from scratch. I started out by trying to make changes to the original std.path, but quickly found that I had to change so much it was better to start with a clean slate. As long as the module is a part of my own library, and doesn't contain anyone else's code, I'll only put my name on it. When it gets included in Phobos, and I add the remaining functions (fcmp, fnmatch, fncharmatch and expandTilde), I will of course be sure to list all authors. That makes sense. It's just that if you didn't rewrite it from scratch, the previous authors would need to be there, and we don't want to mess up on copyright notices, since that could conveivably cause problems at some point if we do mess them up. - Jonathan M Davis
Re: Proposal for std.path replacement
On Sun, 06 Mar 2011 09:37:15 +0100, Rainer Schuetze wrote: Looks good overall. I have a few comments and nitpicks though: basename(dir/subdir/) -- subdir directory(dir/subdir/) -- dir Is this what everybody expects? I'm not sure, but another possibility would be to treat these as if dir/subdir/. is passed. I don't know about everybody, but it is what *NIX users expect, at least. I have written those functions so they adhere to the POSIX requirements for the 'basename' and 'dirname' commands. What is the result of directory(/) or directory(d:/)? / and d:/, respectively. The first is what 'dirname' prints, and the second is the natural extension to Windows paths. (I believe I have covered most corner cases in the unittests. I think it would just be confusing to add all of them to the documentation.) extension(file) -- extension(file.ext) -- ext What about file.? I tried it on NTFS, but trailing '.' seems to always be cut off. Is it possible to create such a file on unix systems? If yes, you won't be able to recreate it from the result of basename() and extension(). Good point. I don't know if there is any kind of precedent here. What do others think? What about network shares like \\server\share\dir\file? Maybe it should also be shown in the examples? Does the \\server part need special consideration? Hmm.. that's another good point. I haven't even though of those, but they should probably be covered as well. I'll look into it. -Lars
Re: Proposal for std.path replacement
Rainer Schuetze wrote: Looks good overall. I have a few comments and nitpicks though: basename(dir/subdir/) -- subdir directory(dir/subdir/) -- dir I would say: basename (dir/subdir/) - (or .) dirname (dir/subdir/) - dir/subdir basename (dir/subdir) - subdir dirname (dir/subdir) - dir Same as Python does. Is this what everybody expects? I'm not sure, but another possibility would be to treat these as if dir/subdir/. is passed. What is the result of directory(/) or directory(d:/)? extension(file) -- extension(file.ext) -- ext extension (file) - extension (file.ext) - .ext extension (file.)- . What about file.? I tried it on NTFS, but trailing '.' seems to always be cut off. Is it possible to create such a file on unix systems? If yes, you won't be able to recreate it from the result of basename() and extension(). Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: Proposal for std.path replacement
On Sat, 05 Mar 2011 14:33:07 -0800, Jonathan M Davis wrote: On Saturday 05 March 2011 08:32:55 Lars T. Kyllingstad wrote: On Fri, 04 Mar 2011 08:14:44 -0500, Nick Sabalausky wrote: Lars T. Kyllingstad public@kyllingen.NOSPAMnet wrote in message news:ikofkc$322$1...@digitalmars.com... As mentioned in the std.path.getName(): Screwy by design? thread, I started working on a rewrite of std.path a long time ago, but I got sidetracked by other things. The recent discussion got me working on it again, and it turned out there wasn't that much left to be done. So here it is, please comment: http://kyllingen.net/code/ltk/doc/path.html https://github.com/kyllingstad/ltk/blob/master/ltk/path.d I don't want to jinx it, but there seems to be a lot of agreement in this thread. Seriously, how often does that happen around here? :) Not too often, so I take it as a good sign that I'm onto something. ;) The only disagreement seems to be about the naming, so let's have a round of voting. Here are a few alternatives for each function. Please say which ones you prefer. * dirSeparator, dirSep, sep dirSep and pathSep. Having Separator in the name is unnecessarily long. * currentDirSymbol, currentDirSym, curDirSymbol currDirSym and parentDirSym (and currDirSymbol and parentDirSymbol if abbreviating both current and symbol is too much). Shorter but still quite clear. I would _definitely_ use two r's when abbreviating current though, since current has two r's. I confess that it' a major pet peeve of mine when I see current abbreviate with one r. It feels like it's being spelled wrong, since current has two r's. * basename, baseName, filename, fileName baseName * dirname, dirName, directory, getDir, getDirName dirName * drivename, driveName, drive, getDrive, getDriveName driveLetter would probably be better actually - though it _could_ be more than one letter if someone has an insane number of drives (it's usually referred to as a drive letter though). Barring that, drive would be fine (as long as it's a property). Interestingly, it seems drive names are actually restricted to one letter. See the last paragraph of this section: http://en.wikipedia.org/wiki/Drive_letter#Common_assignments -Lars
Re: Proposal for std.path replacement
On Sunday 06 March 2011 04:11:35 Lars T. Kyllingstad wrote: On Sat, 05 Mar 2011 14:33:07 -0800, Jonathan M Davis wrote: On Saturday 05 March 2011 08:32:55 Lars T. Kyllingstad wrote: On Fri, 04 Mar 2011 08:14:44 -0500, Nick Sabalausky wrote: Lars T. Kyllingstad public@kyllingen.NOSPAMnet wrote in message news:ikofkc$322$1...@digitalmars.com... As mentioned in the std.path.getName(): Screwy by design? thread, I started working on a rewrite of std.path a long time ago, but I got sidetracked by other things. The recent discussion got me working on it again, and it turned out there wasn't that much left to be done. So here it is, please comment: http://kyllingen.net/code/ltk/doc/path.html https://github.com/kyllingstad/ltk/blob/master/ltk/path.d I don't want to jinx it, but there seems to be a lot of agreement in this thread. Seriously, how often does that happen around here? :) Not too often, so I take it as a good sign that I'm onto something. ;) The only disagreement seems to be about the naming, so let's have a round of voting. Here are a few alternatives for each function. Please say which ones you prefer. * dirSeparator, dirSep, sep dirSep and pathSep. Having Separator in the name is unnecessarily long. * currentDirSymbol, currentDirSym, curDirSymbol currDirSym and parentDirSym (and currDirSymbol and parentDirSymbol if abbreviating both current and symbol is too much). Shorter but still quite clear. I would _definitely_ use two r's when abbreviating current though, since current has two r's. I confess that it' a major pet peeve of mine when I see current abbreviate with one r. It feels like it's being spelled wrong, since current has two r's. * basename, baseName, filename, fileName baseName * dirname, dirName, directory, getDir, getDirName dirName * drivename, driveName, drive, getDrive, getDriveName driveLetter would probably be better actually - though it _could_ be more than one letter if someone has an insane number of drives (it's usually referred to as a drive letter though). Barring that, drive would be fine (as long as it's a property). Interestingly, it seems drive names are actually restricted to one letter. See the last paragraph of this section: http://en.wikipedia.org/wiki/Drive_letter#Common_assignments I could have sworn that I'd seen something which allowed you to assign two- letter names to drives instead of just one... Oh well, it's not like two-letter drive names would be common anyway. That just seems like driveLetter is that much better a name though - especially since driveLetter is unambiguously a Windows thing then as opposed to some general HDD thing. - Jonathan M Davis
Re: Proposal for std.path replacement
On Sunday 06 March 2011 03:56:53 Lars T. Kyllingstad wrote: On Sun, 06 Mar 2011 09:37:15 +0100, Rainer Schuetze wrote: Looks good overall. I have a few comments and nitpicks though: basename(dir/subdir/) -- subdir directory(dir/subdir/) -- dir Is this what everybody expects? I'm not sure, but another possibility would be to treat these as if dir/subdir/. is passed. I don't know about everybody, but it is what *NIX users expect, at least. I have written those functions so they adhere to the POSIX requirements for the 'basename' and 'dirname' commands. If there's a standard way to deal with that, then that's probably best. What is the result of directory(/) or directory(d:/)? / and d:/, respectively. The first is what 'dirname' prints, and the second is the natural extension to Windows paths. (I believe I have covered most corner cases in the unittests. I think it would just be confusing to add all of them to the documentation.) extension(file) -- extension(file.ext) -- ext What about file.? I tried it on NTFS, but trailing '.' seems to always be cut off. Is it possible to create such a file on unix systems? If yes, you won't be able to recreate it from the result of basename() and extension(). Good point. I don't know if there is any kind of precedent here. What do others think? I kind of like how your extension doesn't include the . in it, since you'd often want to remove it anyway, but given this particular ambiguity, I think that it's probably better to go with the old way of including the . in the extension. - Jonathan M Davis
Re: Proposal for std.path replacement
On Sat, 05 Mar 2011 16:32:55 +, Lars T. Kyllingstad wrote: On Fri, 04 Mar 2011 08:14:44 -0500, Nick Sabalausky wrote: Lars T. Kyllingstad public@kyllingen.NOSPAMnet wrote in message news:ikofkc$322$1...@digitalmars.com... As mentioned in the std.path.getName(): Screwy by design? thread, I started working on a rewrite of std.path a long time ago, but I got sidetracked by other things. The recent discussion got me working on it again, and it turned out there wasn't that much left to be done. So here it is, please comment: http://kyllingen.net/code/ltk/doc/path.html https://github.com/kyllingstad/ltk/blob/master/ltk/path.d I don't want to jinx it, but there seems to be a lot of agreement in this thread. Seriously, how often does that happen around here? :) Not too often, so I take it as a good sign that I'm onto something. ;) The only disagreement seems to be about the naming, so let's have a round of voting. Here are a few alternatives for each function. Please say which ones you prefer. * dirSeparator, dirSep, sep * currentDirSymbol, currentDirSym, curDirSymbol * basename, baseName, filename, fileName * dirname, dirName, directory, getDir, getDirName * drivename, driveName, drive, getDrive, getDriveName * extension, ext, getExt, getExtension * stripExtension, stripExt (The same convention will be used for stripExtension, replaceExtension and defaultExtension.) In summary, it seems currentDirSymbol, baseName, dirName and driveName are clear winners. Less clear, but still voted for by the majority, are extension and stripExtension. It is a tie between dirSep and dirSeparator. Below are the votes I counted. And before you say hey, I didn't know we could make suggestions of our own, or why did that guy get several votes?, this was by no means a formal vote. It was just trying to get a feel for people's preferences. Before the module gets accepted into Phobos there will have to be a formal review process, so there is still a lot of opportunity to fight over naming. :) dirSep: 3 (Nick Sabalausky, spir, Jonathan M. Davis) dirSeparator: 3 (Bekenn, Jim, J Chapman) currDirSym: 1 (Jonathan M. Davis) currDirSymbol: 2 (Nick Sabalausky, Jonathan M. Davis) path.current: 1 (Andrej Mitrovic) currentDirSymbol: 4 (Bekenn, Jim, J Chapman, spir) baseName: 6 (Nick Sabalausky, Bekenn, Jim, J Chapman, spir, Jonathan M. Davis) baseFileName: 1 (Nick Sabalausky) fileName: 1 (spir) basename: 1 (Andrei Alexandrescu) dirName: 6 (Nick Sabalausky, Bekenn, Jim, spir, Jonathan M. Davis, David Nadlinger) directory: 1 (Nick Sabalausky) getDirName: 2 (J Chapman, spir) dirname: 1 (Andrei Alexandrescu) driveName: 4 (Nick Sabalausky, Bekenn, Jim, spir) drive: 2 (Nick Sabalausky, Jonathan M. Davis) getDriveName: 2 (J Chapman, spir) driveLetter: 1 (Jonathan M. Davis) ext: 1 (Nick Sabalausky) extension: 2 (Bekenn, Jim) getExtension: 1 (J Chapman) stripExt: 2 (Nick Sabalausky, Jonathan M. Davis) stripExtension: 3 (Bekenn, Jim, J Chapman)
Re: Naming convention in Phobos
Jim Wrote: Okay, so there's a discussion about identifier names in the proposed std.path replacement -- should they be abbreviated or not? Should we perhaps seek to have a consistent naming convention for all identifier names in Phobos? Some of the potential benefits: Legibility, understandability and clarity (reduce ambiguity). Ease in finding a suitable function/class by name. Knowing if it's a cheap or costly function call. Aesthetics and professional appearance. Some properties that I can think of for discussion: Abbreviation (and if so, what to abbreviate and how much)? Preference of commonly used terms in other languages, contexts? Use of get and set prefixes or not (getName() or simply name())? Explicit use of a prefix (example: calc or calculate) for costly operations? Naming of function and template arguments? Uppercase, lowercase, camelcase, underscore in multi-word names? All caps for constants, or different appearance for different types (types, functions, arguments, constants...). What about acronyms: TCP, Tcp? Are there other concerns? #38750;#24120;#36190;#21516;#65292;#23613;#37327;#19981;#20351;#29992;#38271;#21517;#31216;#20294;#20063;#19981;#25490;#26021;#65292;#23398;#20064;java#21629;#21517;#21746;#23398;#65292;#35753;#20840;#19990;#30028;#37117;#30475;#24471;#25026;#65288;#38750;#33521;#35821;#22269;#23478;#65289; #22914;#26524;#26377;#22810;#20010;#21516;#20041;#35789;#65292;#35831;#20351;#29992;#35789;#39057;#26356;#39640;#30340; Very much in favor! Try not to use the long name But not exclusive, Learning java naming philosophy, If you have multiple synonyms, Please use the word frequency higher, Let the whole world are able to understand (non-English speaking countries) thank you very much! dolive
Re: Naming convention in Phobos
Jim Wrote: Okay, so there's a discussion about identifier names in the proposed std.path replacement -- should they be abbreviated or not? Should we perhaps seek to have a consistent naming convention for all identifier names in Phobos? Some of the potential benefits: Legibility, understandability and clarity (reduce ambiguity). Ease in finding a suitable function/class by name. Knowing if it's a cheap or costly function call. Aesthetics and professional appearance. Some properties that I can think of for discussion: Abbreviation (and if so, what to abbreviate and how much)? Preference of commonly used terms in other languages, contexts? Use of get and set prefixes or not (getName() or simply name())? Explicit use of a prefix (example: calc or calculate) for costly operations? Naming of function and template arguments? Uppercase, lowercase, camelcase, underscore in multi-word names? All caps for constants, or different appearance for different types (types, functions, arguments, constants...). What about acronyms: TCP, Tcp? Are there other concerns? Phobos naming convention should be a major adjustment! thanks all ! dolive
Re: Proposal for std.path replacement
Lars T. Kyllingstad public@kyllingen.NOSPAMnet wrote in message news:ikvsq5$1qr9$2...@digitalmars.com... On Sun, 06 Mar 2011 09:37:15 +0100, Rainer Schuetze wrote: Looks good overall. I have a few comments and nitpicks though: basename(dir/subdir/) -- subdir directory(dir/subdir/) -- dir Is this what everybody expects? I'm not sure, but another possibility would be to treat these as if dir/subdir/. is passed. I don't know about everybody, but it is what *NIX users expect, at least. I have written those functions so they adhere to the POSIX requirements for the 'basename' and 'dirname' commands. I initially felt somewhat uncomfortable with the idea of that behavior, but then I realized two things: 1. You don't have to constantly worry about trailing slash vs no trailing slash and remember the different semantics. (The trailing slash vs no trailing slash matter can be a real pain.) 2. It'll always treat a path to a directory the same way as a path to a file. (Consistency is nice. Especially since you don't always know if something is intended to be a file or directory.)
Re: Naming convention in Phobos
Jim bitcir...@yahoo.com wrote in message news:ikvped$1o35$1...@digitalmars.com... Okay, so there's a discussion about identifier names in the proposed std.path replacement -- should they be abbreviated or not? Should we perhaps seek to have a consistent naming convention for all identifier names in Phobos? Some of the potential benefits: Legibility, understandability and clarity (reduce ambiguity). Ease in finding a suitable function/class by name. Knowing if it's a cheap or costly function call. Aesthetics and professional appearance. Some properties that I can think of for discussion: Abbreviation (and if so, what to abbreviate and how much)? Preference of commonly used terms in other languages, contexts? Use of get and set prefixes or not (getName() or simply name())? Explicit use of a prefix (example: calc or calculate) for costly operations? Naming of function and template arguments? Uppercase, lowercase, camelcase, underscore in multi-word names? All caps for constants, or different appearance for different types (types, functions, arguments, constants...). What about acronyms: TCP, Tcp? Are there other concerns? I think that every individual variable, function and type in Phobos should use the naming convention of whatever random language the author happened to be thinking of when they wrote it. That way Phobos won't seem messy. Plus, the lack of any sensible rules would make it super-easy to remember all the different spellings, punctuations and capitalizations.
Using map instead of iteration
I have a code fragment:
auto threads = new Thread[numberOfThreads] ;
foreach ( i ; 0 .. numberOfThreads ) {
void delegate ( ) closedPartialSum ( ) {
immutable id = i ;
return ( ) { partialSum ( id , sliceSize , delta ) ; } ;
}
threads[i] = new Thread ( closedPartialSum ) ;
}
which clearly should be doable using map from std.algorithm. So I
tried:
auto threads = map ! ( function Thread ( int i ) {
void delegate ( ) closedPartialSum ( ) {
immutable id = i ;
return ( ) { partialSum ( id , sliceSize , delta ) ; } ;
}
return new Thread ( closedPartialSum ) ;
} ) ( 0 .. numberOfThreads )
which fails:
pi_d2_threadsGlobalState.d(41): found '..' when expecting ','
pi_d2_threadsGlobalState.d(57): semicolon expected following auto
declaration, not 'foreach'
So clearly 0 .. numberOfThreads only means a range of integers in a
foreach or array index only and not everywhere as it does in all
sensible languages :-((
I am clearly missing something, anyone any ideas?
Thanks.
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: Using map instead of iteration
Russel Winder rus...@russel.org.uk wrote:
I have a code fragment:
auto threads = new Thread[numberOfThreads] ;
foreach ( i ; 0 .. numberOfThreads ) {
void delegate ( ) closedPartialSum ( ) {
immutable id = i ;
return ( ) { partialSum ( id , sliceSize , delta ) ; } ;
}
threads[i] = new Thread ( closedPartialSum ) ;
}
which clearly should be doable using map from std.algorithm. So I
tried:
auto threads = map ! ( function Thread ( int i ) {
void delegate ( ) closedPartialSum ( ) {
immutable id = i ;
return ( ) { partialSum ( id , sliceSize , delta ) ; } ;
}
return new Thread ( closedPartialSum ) ;
} ) ( 0 .. numberOfThreads )
which fails:
pi_d2_threadsGlobalState.d(41): found '..' when expecting ','
pi_d2_threadsGlobalState.d(57): semicolon expected following auto
declaration, not 'foreach'
So clearly 0 .. numberOfThreads only means a range of integers in a
foreach or array index only and not everywhere as it does in all
sensible languages :-((
I am clearly missing something, anyone any ideas?
You should use std.range.iota(0,numberOfThreads) instead of
0..numberOfThreads. Having a..b return a general interval range
has been proposed numerous times, but nothing has been implemented as
of yet.
If you like syntactic sugar, this is likely the closest you'll get at
this point:
import std.range;
struct _ {
auto opSlice(B,E)(B begin, E end) {
return iota(begin, end);
}
}
// Example:
map!foo( _[0..numberOfThreads] );
--
Simen
Function literals and lambda functions
OK, this one surprised me, all that remains is for me to find out why it
shouldn't have done:
reduce ! ( ( a , b ) { return a + b ; } ) ( 0.0 , outputData )
works just fine, but:
reduce ! ( function double ( double a , double b ) { return a + b ; } )
( 0.0 , outputData )
results in:
pi_d2_sequentialMap.d(45): Error: function
std.algorithm.reduce!(function double(double a, double b)
{
return a + b;
}
).reduce!(double,Map!(partialSum,Tuple!(int,int,double)[])).reduce.__funcliteral1
cannot access frame of function pi_d2_sequentialMap.execute.__funcliteral1
pi_d2_sequentialMap.d(45): Error: function
std.algorithm.reduce!(function double(double a, double b)
{
return a + b;
}
).reduce!(double,Map!(partialSum,Tuple!(int,int,double)[])).reduce.__funcliteral1
cannot access frame of function pi_d2_sequentialMap.execute.__funcliteral1
which I think qualifies for the label incomprehensible. Not to
mention repetitious.
PS If you ask why not:
reduce ! ( a+b ) ( 0.0 , outputData )
I find this somehow unacceptable. It's the string, its not a function.
Fine, my problem, but that still leaves the above.
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Problem with parallel map
David,
I am not sure how properly to report this in this review period . . .
If I use:
taskPool.reduce ! ( a + b ) ( 0.0 , outputData )
then it works. If however I try:
taskPool.reduce ! ( ( a , b ) { return a + b ; } ) ( 0.0 , outputData )
I get:
pi_d2_parallelMap.d(58): Error: template instance cannot use local
'__dgliteral1(__T2,__T3)' as parameter to non-global template
reduce(functions...)
which doesn't really work for me :-((
If I try
taskPool.reduce ! ( function double ( double a , double b ) { return a
+ b ; } ) ( 0.0 , outputData )
then I get:
pi_d2_parallelMap.d(59): Error: function std.parallelism.__funcliteral1
cannot access frame of function pi_d2_parallelMap.execute.__funcliteral1
pi_d2_parallelMap.d(59): Error: function std.parallelism.__funcliteral1
cannot access frame of function pi_d2_parallelMap.execute.__funcliteral1
which is just the error I get with the sequential map and so a compiler
problem, I just added it for completeness.
Thanks.
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: Proposal for std.path replacement
On 03/06/2011 01:35 AM, Nick Sabalausky wrote: spirdenis.s...@gmail.com wrote in message news:mailman.2213.1299361218.4748.digitalmar...@puremagic.com... On 03/05/2011 09:57 PM, Nick Sabalausky wrote: * currentDirSymbol, currentDirSym, curDirSymbol currDirSymbol, But I'd be fine with the others too. currDirSymbol not on the list ;-) I deliberately added it :) I think it's better than curDirSymbol (but like I said, I can go either way.) I agree with you and Jonathan about that point. Also find that 'dir' is enough, esp in context, because it can hardly be misinterpreted. And it's very used in programming (not only a pair of PLs) and in computer use in general. Thus, it's one rare case where I find abbr ok. Denis -- _ vita es estrany spir.wikidot.com
Re: Problem with parallel map
http://d.puremagic.com/issues/show_bug.cgi?id=5710
It's a DMD issue. I've been meaning to report it for a while.
Unfortunately making a workaround for it would be a huge PITA at best
and impossible in the toughest use cases.
On 3/6/2011 9:12 AM, Russel Winder wrote:
David,
I am not sure how properly to report this in this review period . . .
If I use:
taskPool.reduce ! ( a + b ) ( 0.0 , outputData )
then it works. If however I try:
taskPool.reduce ! ( ( a , b ) { return a + b ; } ) ( 0.0 , outputData )
I get:
pi_d2_parallelMap.d(58): Error: template instance cannot use local
'__dgliteral1(__T2,__T3)' as parameter to non-global template
reduce(functions...)
which doesn't really work for me :-((
If I try
taskPool.reduce ! ( function double ( double a , double b ) { return a
+ b ; } ) ( 0.0 , outputData )
then I get:
pi_d2_parallelMap.d(59): Error: function
std.parallelism.__funcliteral1 cannot access frame of function
pi_d2_parallelMap.execute.__funcliteral1
pi_d2_parallelMap.d(59): Error: function
std.parallelism.__funcliteral1 cannot access frame of function
pi_d2_parallelMap.execute.__funcliteral1
which is just the error I get with the sequential map and so a compiler
problem, I just added it for completeness.
Thanks.
Re: Proposal for std.path replacement
On 03/06/2011 09:37 AM, Rainer Schuetze wrote: Looks good overall. I have a few comments and nitpicks though: I think all your questions are sensible, Rainer. basename(dir/subdir/) -- subdir directory(dir/subdir/) -- dir Is this what everybody expects? I'm not sure, but another possibility would be to treat these as if dir/subdir/. is passed. What is the result of directory(/) or directory(d:/)? Depends. We must make clear whether such funcs work: 1. indifferently for file and dir names, in which case we get the above results, 2. differently for file dir names, in which case we would have dir/subdir/ as result of both operations above, 3. only for file names, in which case we throw an error when these functions are called on dir names. I find both solutions 1. and 2. conceptually problematic; the second one only a bit less. Maybe the only sensible choice is 3.? extension(file) -- extension(file.ext) -- ext What about file.? I tried it on NTFS, but trailing '.' seems to always be cut off. Is it possible to create such a file on unix systems? If yes, you won't be able to recreate it from the result of basename() and extension(). This is /really/ problematic, indeed! The splitting operation *must* be reversable in all cases. In other other words, file name/path recomposition must be symmetric of splitting it. What about network shares like \\server\share\dir\file? Maybe it should also be shown in the examples? Does the \\server part need special consideration? I think there should be a special case similar to windows drive names. Maybe, instead of a notion of drive, have a notion of 'device', which could then cover network connexion. Then, a full file path/name would be composed of: deviceName | dirName || baseName | extension One issue is defining the appropriate 'joint'/sep between deviceName dirName. (See split -- recomposition above.) What do you think? Denis -- _ vita es estrany spir.wikidot.com
Re: Proposal for std.path replacement
On 03/06/2011 12:50 PM, Jérôme M. Berger wrote: Rainer Schuetze wrote: Looks good overall. I have a few comments and nitpicks though: basename(dir/subdir/) -- subdir directory(dir/subdir/) -- dir I would say: basename (dir/subdir/) - (or .) dirname (dir/subdir/) - dir/subdir basename (dir/subdir) - subdir dirname (dir/subdir) - dir Same as Python does. Is this what everybody expects? I'm not sure, but another possibility would be to treat these as if dir/subdir/. is passed. What is the result of directory(/) or directory(d:/)? extension(file) -- extension(file.ext) -- ext extension (file) - extension (file.ext) - .ext extension (file.)- . What about file.? I tried it on NTFS, but trailing '.' seems to always be cut off. Is it possible to create such a file on unix systems? If yes, you won't be able to recreate it from the result of basename() and extension(). This solves the issue of recomposing a file path/name from its parts. But it's not what people mean, expect, and need with the notion of extension. We would have to remember this (weird) behaviour of the extension() function; and systematically write strip off starting '.'. Then, we get caught when the result is ! Thus, we must add a check: extension = path.extension(foo); if (extension[0] == '.') extension = extension[1..$]; Very nice... Denis -- _ vita es estrany spir.wikidot.com
Re: Proposal for std.path replacement
On 03/06/2011 12:56 PM, Lars T. Kyllingstad wrote: On Sun, 06 Mar 2011 09:37:15 +0100, Rainer Schuetze wrote: Looks good overall. I have a few comments and nitpicks though: basename(dir/subdir/) -- subdir directory(dir/subdir/) -- dir Is this what everybody expects? I'm not sure, but another possibility would be to treat these as if dir/subdir/. is passed. I don't know about everybody, but it is what *NIX users expect, at least. I have written those functions so they adhere to the POSIX requirements for the 'basename' and 'dirname' commands. What is the result of directory(/) or directory(d:/)? / and d:/, respectively. The first is what 'dirname' prints, and the second is the natural extension to Windows paths. (I believe I have covered most corner cases in the unittests. I think it would just be confusing to add all of them to the documentation.) extension(file) --extension(file.ext) -- ext What about file.? I tried it on NTFS, but trailing '.' seems to always be cut off. Is it possible to create such a file on unix systems? If yes, you won't be able to recreate it from the result of basename() and extension(). Good point. I don't know if there is any kind of precedent here. What do others think? What about network shares like \\server\share\dir\file? Maybe it should also be shown in the examples? Does the \\server part need special consideration? Hmm.. that's another good point. I haven't even though of those, but they should probably be covered as well. I'll look into it. What about extending the notion of 'device' (see other post) to cover 'http://' and ftp://;? Would it be complicated? Denis -- _ vita es estrany spir.wikidot.com
Re: Function literals and lambda functions
Russel Winder:
reduce ! ( ( a , b ) { return a + b ; } ) ( 0.0 , outputData )
works just fine, but:
reduce ! ( function double ( double a , double b ) { return a + b ; }
) ( 0.0 , outputData )
import std.stdio, std.algorithm, std.range;
void main() {
auto outputData = iota(1.0, 10.0);
auto r1 = reduce!((a, b){ return a + b; })(0.0, outputData);
writeln(r1);
auto r2 = reduce!((double a, double b){ return a + b; })(0.0, outputData);
writeln(r2);
auto r3 = reduce!(a + b)(0.0, outputData);
writeln(r3);
auto r4 = reduce!q{a + b}(0.0, outputData);
writeln(r4);
auto r5 = reduce!q{a + b}(outputData); // not exactly the same
writeln(r5);
}
Bye,
bearophile
Re: Naming convention in Phobos
Nick Sabalausky Wrote: Jim bitcir...@yahoo.com wrote in message news:ikvped$1o35$1...@digitalmars.com... Okay, so there's a discussion about identifier names in the proposed std.path replacement -- should they be abbreviated or not? Should we perhaps seek to have a consistent naming convention for all identifier names in Phobos? Some of the potential benefits: Legibility, understandability and clarity (reduce ambiguity). Ease in finding a suitable function/class by name. Knowing if it's a cheap or costly function call. Aesthetics and professional appearance. Some properties that I can think of for discussion: Abbreviation (and if so, what to abbreviate and how much)? Preference of commonly used terms in other languages, contexts? Use of get and set prefixes or not (getName() or simply name())? Explicit use of a prefix (example: calc or calculate) for costly operations? Naming of function and template arguments? Uppercase, lowercase, camelcase, underscore in multi-word names? All caps for constants, or different appearance for different types (types, functions, arguments, constants...). What about acronyms: TCP, Tcp? Are there other concerns? I think that every individual variable, function and type in Phobos should use the naming convention of whatever random language the author happened to be thinking of when they wrote it. That way Phobos won't seem messy. Plus, the lack of any sensible rules would make it super-easy to remember all the different spellings, punctuations and capitalizations. I would also add to the above excellent point that in order to prevent unworthy people of programming in the holly D programming language we must require every D programmer to be fluent in English, Latin and Greek (including cultural references to movies and such), have *at least* expert Unix hacking credentials, have a certified MSFT engineering diploma, be Guru level programmers in all of the following: c, c++, Haskell, Perl, APL, LISP, ALGOL and COBOL. AND, lest we forget, they must code ONLY in a terminal based text-editor with 80 character wide lines.
Re: Using map instead of iteration
On 03/06/2011 02:43 PM, Russel Winder wrote:
I have a code fragment:
auto threads = new Thread[numberOfThreads] ;
foreach ( i ; 0 .. numberOfThreads ) {
void delegate ( ) closedPartialSum ( ) {
immutable id = i ;
return ( ) { partialSum ( id , sliceSize , delta ) ; } ;
}
threads[i] = new Thread ( closedPartialSum ) ;
}
which clearly should be doable using map from std.algorithm. So I
tried:
auto threads = map ! ( function Thread ( int i ) {
void delegate ( ) closedPartialSum ( ) {
immutable id = i ;
return ( ) { partialSum ( id , sliceSize , delta ) ; } ;
}
return new Thread ( closedPartialSum ) ;
} ) ( 0 .. numberOfThreads )
which fails:
pi_d2_threadsGlobalState.d(41): found '..' when expecting ','
pi_d2_threadsGlobalState.d(57): semicolon expected following auto
declaration, not 'foreach'
So clearly 0 .. numberOfThreads only means a range of integers in a
foreach or array index only and not everywhere as it does in all
sensible languages :-((
I am clearly missing something, anyone any ideas?
Without trying to study the code's detainls: ( 0 .. numberOfThreads ) has
very few chances to be accepted by the parser ;-)
Note: there is no interval literal in D. Instead uses of i..j in slicing and
foreach both are pure syntactic honey.
Denis
--
_
vita es estrany
spir.wikidot.com
Re: Proposal for std.path replacement
On 3/6/11 6:31 AM, Lars T. Kyllingstad wrote: In summary, it seems currentDirSymbol, baseName, dirName and driveName are clear winners. Less clear, but still voted for by the majority, are extension and stripExtension. It is a tie between dirSep and dirSeparator. Below are the votes I counted. And before you say hey, I didn't know we could make suggestions of our own, or why did that guy get several votes?, this was by no means a formal vote. It was just trying to get a feel for people's preferences. Before the module gets accepted into Phobos there will have to be a formal review process, so there is still a lot of opportunity to fight over naming. :) I think whatever you choose will not please everybody, so just choose something and stick with it. Regarding all the extension naming stuff, I suggest you go with the suffix nomenclature which is more general and applicable to all OSs. Regarding semantics, consistently strip the trailing slash. It is unequivocally the best semantics (and incidentally or not it's what Unix's dirname and basename do). If rsync et al need it, they can always look for it in the initial parameter. The reality of the matter is that you will never be able to accommodate all use cases there are with maximum convenience. You may want to prepare this for review after April 1st, when the review for std.parallelism ends. There is good signal in the exchange so far, but from here on this discussion could go on forever and shift focus away from std.parallelism. Andrei
Re: Function literals and lambda functions
On 03/06/2011 03:03 PM, Russel Winder wrote: PS If you ask why not: reduce ! ( a+b ) ( 0.0 , outputData ) I find this somehow unacceptable. It's the string, its not a function. Fine, my problem, but that still leaves the above. You are not the only one ;-). The ugliest trick I have ever seen in a language. Even worse than BASIC's 'eval'. But we're far from having AST methods in D, I guess. Denis -- _ vita es estrany spir.wikidot.com
Re: Proposal for std.path replacement
On Sun, 06 Mar 2011 15:54:19 +0100, spir wrote: On 03/06/2011 12:56 PM, Lars T. Kyllingstad wrote: On Sun, 06 Mar 2011 09:37:15 +0100, Rainer Schuetze wrote: Looks good overall. I have a few comments and nitpicks though: basename(dir/subdir/) -- subdir directory(dir/subdir/) -- dir Is this what everybody expects? I'm not sure, but another possibility would be to treat these as if dir/subdir/. is passed. I don't know about everybody, but it is what *NIX users expect, at least. I have written those functions so they adhere to the POSIX requirements for the 'basename' and 'dirname' commands. What is the result of directory(/) or directory(d:/)? / and d:/, respectively. The first is what 'dirname' prints, and the second is the natural extension to Windows paths. (I believe I have covered most corner cases in the unittests. I think it would just be confusing to add all of them to the documentation.) extension(file) --extension(file.ext) -- ext What about file.? I tried it on NTFS, but trailing '.' seems to always be cut off. Is it possible to create such a file on unix systems? If yes, you won't be able to recreate it from the result of basename() and extension(). Good point. I don't know if there is any kind of precedent here. What do others think? What about network shares like \\server\share\dir\file? Maybe it should also be shown in the examples? Does the \\server part need special consideration? Hmm.. that's another good point. I haven't even though of those, but they should probably be covered as well. I'll look into it. What about extending the notion of 'device' (see other post) to cover 'http://' and ftp://;? Would it be complicated? I don't think std.path should handle general URIs. It should only have to deal with the kind of paths you can pass to the functions in std.file and std.stdio. -Lars
Re: Naming convention in Phobos
On 3/6/11 9:27 AM, foobar wrote: Nick Sabalausky Wrote: Jimbitcir...@yahoo.com wrote in message news:ikvped$1o35$1...@digitalmars.com... Okay, so there's a discussion about identifier names in the proposed std.path replacement -- should they be abbreviated or not? Should we perhaps seek to have a consistent naming convention for all identifier names in Phobos? Some of the potential benefits: • Legibility, understandability and clarity (reduce ambiguity). • Ease in finding a suitable function/class by name. • Knowing if it's a cheap or costly function call. • Aesthetics and professional appearance. Some properties that I can think of for discussion: • Abbreviation (and if so, what to abbreviate and how much)? • Preference of commonly used terms in other languages, contexts? • Use of get and set prefixes or not (getName() or simply name())? • Explicit use of a prefix (example: calc or calculate) for costly operations? • Naming of function and template arguments? • Uppercase, lowercase, camelcase, underscore in multi-word names? All caps for constants, or different appearance for different types (types, functions, arguments, constants...). What about acronyms: TCP, Tcp? Are there other concerns? I think that every individual variable, function and type in Phobos should use the naming convention of whatever random language the author happened to be thinking of when they wrote it. That way Phobos won't seem messy. Plus, the lack of any sensible rules would make it super-easy to remember all the different spellings, punctuations and capitalizations. I would also add to the above excellent point that in order to prevent unworthy people of programming in the holly You have a typo there. Andrei
Re: Naming convention in Phobos
On 03/06/2011 04:27 PM, foobar wrote: Are there other concerns? I think that every individual variable, function and type in Phobos should use the naming convention of whatever random language the author happened to be thinking of when they wrote it. That way Phobos won't seem messy. Plus, the lack of any sensible rules would make it super-easy to remember all the different spellings, punctuations and capitalizations. I would also add to the above excellent point that in order to prevent unworthy people of programming in the holly D programming language we must require every D programmer to be fluent in English, Latin and Greek (including cultural references to movies and such), have *at least* expert Unix hacking credentials, have a certified MSFT engineering diploma, be Guru level programmers in all of the following: c, c++, Haskell, Perl, APL, LISP, ALGOL and COBOL. AND, lest we forget, they must code ONLY in a terminal based text-editor with 80 character wide lines. Thus, if I understand correctly, the D community finally let down all prerequisites in fields of mathematical logics, philosophy of language, and metaphysics of automata? Or what? Denis -- _ vita es estrany spir.wikidot.com
Re: dmd, x64 and Windows
On 3/6/11, Caligo iteronve...@gmail.com wrote: Kind of off-topic, but does anyone know if GDC is still scheduled to be included in GCC 4.7? Dunno. But this raises an interesting observation. If GDC gets included in the GCC mainline, I wonder if the MinGW and TDM-MinGW teams will start getting interest in D. Of course, this doesn't automatically mean they'll jump on the bandwagon and start supporting D. Afaik the MinGW team dropped support for Java (?), so I don't think they feel they should support every language that GCC supports. Still, this might get people more interested in D.
Re: Proposal for std.path replacement
Lars T. Kyllingstad wrote: On Sun, 06 Mar 2011 09:37:15 +0100, Rainer Schuetze wrote: What about file.? I tried it on NTFS, but trailing '.' seems to always be cut off. Is it possible to create such a file on unix systems? If yes, you won't be able to recreate it from the result of basename() and extension(). Good point. I don't know if there is any kind of precedent here. What do others think? Maybe special casing similar to the hidden files starting with '.': basename(file.) -- file. extension(file.) --
Re: Problem with parallel map
On Sun, 2011-03-06 at 09:33 -0500, dsimcha wrote:
http://d.puremagic.com/issues/show_bug.cgi?id=5710
It's a DMD issue. I've been meaning to report it for a while.
Unfortunately making a workaround for it would be a huge PITA at best
and impossible in the toughest use cases.
OK, I signed up to the issue, but there seems no way of voting for it to
try and raise its chance of being fixed.
Despite my personal dislike of this use of string to write functions, I
can live with it in this case, so I am not worried about a workaround in
std.parallelism -- though a DMD fix would be good.
Thanks.
On 3/6/2011 9:12 AM, Russel Winder wrote:
David,
I am not sure how properly to report this in this review period . . .
If I use:
taskPool.reduce ! ( a + b ) ( 0.0 , outputData )
then it works. If however I try:
taskPool.reduce ! ( ( a , b ) { return a + b ; } ) ( 0.0 ,
outputData )
I get:
pi_d2_parallelMap.d(58): Error: template instance cannot use local
'__dgliteral1(__T2,__T3)' as parameter to non-global template
reduce(functions...)
which doesn't really work for me :-((
If I try
taskPool.reduce ! ( function double ( double a , double b ) { return a
+ b ; } ) ( 0.0 , outputData )
then I get:
pi_d2_parallelMap.d(59): Error: function
std.parallelism.__funcliteral1 cannot access frame of function
pi_d2_parallelMap.execute.__funcliteral1
pi_d2_parallelMap.d(59): Error: function
std.parallelism.__funcliteral1 cannot access frame of function
pi_d2_parallelMap.execute.__funcliteral1
which is just the error I get with the sequential map and so a compiler
problem, I just added it for completeness.
Thanks.
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: Naming convention in Phobos
Andrei Alexandrescu Wrote: On 3/6/11 9:27 AM, foobar wrote: Nick Sabalausky Wrote: Jimbitcir...@yahoo.com wrote in message news:ikvped$1o35$1...@digitalmars.com... Okay, so there's a discussion about identifier names in the proposed std.path replacement -- should they be abbreviated or not? Should we perhaps seek to have a consistent naming convention for all identifier names in Phobos? Some of the potential benefits: Legibility, understandability and clarity (reduce ambiguity). Ease in finding a suitable function/class by name. Knowing if it's a cheap or costly function call. Aesthetics and professional appearance. Some properties that I can think of for discussion: Abbreviation (and if so, what to abbreviate and how much)? Preference of commonly used terms in other languages, contexts? Use of get and set prefixes or not (getName() or simply name())? Explicit use of a prefix (example: calc or calculate) for costly operations? Naming of function and template arguments? Uppercase, lowercase, camelcase, underscore in multi-word names? All caps for constants, or different appearance for different types (types, functions, arguments, constants...). What about acronyms: TCP, Tcp? Are there other concerns? I think that every individual variable, function and type in Phobos should use the naming convention of whatever random language the author happened to be thinking of when they wrote it. That way Phobos won't seem messy. Plus, the lack of any sensible rules would make it super-easy to remember all the different spellings, punctuations and capitalizations. I would also add to the above excellent point that in order to prevent unworthy people of programming in the holly You have a typo there. Andrei Well than I must be unworthy of the D community. I must flee before you come chasing me with pitchforks...
Re: Naming convention in Phobos
spir Wrote: On 03/06/2011 04:27 PM, foobar wrote: Are there other concerns? I think that every individual variable, function and type in Phobos should use the naming convention of whatever random language the author happened to be thinking of when they wrote it. That way Phobos won't seem messy. Plus, the lack of any sensible rules would make it super-easy to remember all the different spellings, punctuations and capitalizations. I would also add to the above excellent point that in order to prevent unworthy people of programming in the holly D programming language we must require every D programmer to be fluent in English, Latin and Greek (including cultural references to movies and such), have *at least* expert Unix hacking credentials, have a certified MSFT engineering diploma, be Guru level programmers in all of the following: c, c++, Haskell, Perl, APL, LISP, ALGOL and COBOL. AND, lest we forget, they must code ONLY in a terminal based text-editor with 80 character wide lines. Thus, if I understand correctly, the D community finally let down all prerequisites in fields of mathematical logics, philosophy of language, and metaphysics of automata? Or what? Denis -- _ vita es estrany spir.wikidot.com Oh my, I forgot those! Don't be silly, The D prerequisites can only grow. It is cosmologically impossible to remove anything since it is written in punch-cards (which is worse than writing in stones).
Re: Function literals and lambda functions
On Sun, 2011-03-06 at 10:08 -0500, bearophile wrote:
Russel Winder:
reduce ! ( ( a , b ) { return a + b ; } ) ( 0.0 , outputData )
works just fine, but:
reduce ! ( function double ( double a , double b ) { return a + b ;
} ) ( 0.0 , outputData )
import std.stdio, std.algorithm, std.range;
void main() {
auto outputData = iota(1.0, 10.0);
auto r1 = reduce!((a, b){ return a + b; })(0.0, outputData);
writeln(r1);
auto r2 = reduce!((double a, double b){ return a + b; })(0.0, outputData);
writeln(r2);
auto r3 = reduce!(a + b)(0.0, outputData);
writeln(r3);
auto r4 = reduce!q{a + b}(0.0, outputData);
writeln(r4);
auto r5 = reduce!q{a + b}(outputData); // not exactly the same
writeln(r5);
}
Bye,
bearophile
So why does:
reduce ! ( function double ( double a , double b ) { return a + b ; } )
( 0.0 , outputData )
fail? It implies that a function literal and a lambda are significantly
different things as far as the compiler is concerned.
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: Naming convention in Phobos
foobar f...@bar.com wrote: I would also add to the above excellent point that in order to prevent unworthy people of programming in the holly You have a typo there. Andrei Well than I must be unworthy of the D community. I must flee before you come chasing me with pitchforks... A witch! May we burn it? -- Simen
Re: Using map instead of iteration
On Sun, 2011-03-06 at 14:57 +0100, Simen kjaeraas wrote:
[ . . . ]
You should use std.range.iota(0,numberOfThreads) instead of
0..numberOfThreads. Having a..b return a general interval range
has been proposed numerous times, but nothing has been implemented as
of yet.
Thanks for this pointer.
If you like syntactic sugar, this is likely the closest you'll get at
this point:
import std.range;
struct _ {
auto opSlice(B,E)(B begin, E end) {
return iota(begin, end);
}
}
// Example:
map!foo( _[0..numberOfThreads] );
Interesting. I am not sure I would do this, instead just going with the
explicit iota.
It would be better though if x..y (and x..y) were standard parts of the
syntax.
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: Using map instead of iteration
On Sun, 2011-03-06 at 16:25 +0100, spir wrote: [ . . . ] Without trying to study the code's detainls: ( 0 .. numberOfThreads ) has very few chances to be accepted by the parser ;-) Note: there is no interval literal in D. Instead uses of i..j in slicing and foreach both are pure syntactic honey. Perhaps this needs review. All modern language now have this as an integral way of describing a sequence of values. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Haskell infix syntax
Haskell is full of function calls, so the Haskell designers have used/invented
several different ways to avoid some parenthesys in the code.
From what I've seen if you remove some parenthesis well, in the right places,
the resulting code is less noisy, more readable, and it has less chances to
contain a bug (because syntax noise is a good place for bugs to hide).
One of the ways used to remove some parenthesys is a standard syntax that's
optionally usable on any dyadic function (function with two arguments):
sum a b = a + b
sum 1 5 == 1 `sum` 5
The `name` syntax is just a different way to call a regular function with two
arguments.
In Haskell there is also a way to assign an arbitrary precedence and
associativity to such infix operators, but some Haskell programmers argue that
too much syntax sugar gives troubles (
http://www.haskell.org/haskellwiki/Use_of_infix_operators ).
In D the back tick has a different meaning, and even if in D you use a
different syntax, like just a $ prefix, I don't know how much good this syntax
is for D:
int sum(int x, int y) { return x + y; }
int s = sum(1, sum(5, sum(6, sum(10, 30;
Equals to (associativity of $ is fixed like this):
int s = 1 $sum 5 $sum 6 $sum 10 $sum 30;
So I think it's not worth adding to D.
Bye,
bearophile
Re: Haskell infix syntax
So I think it's not worth adding to D. But if you don't agree... talk. Bye, bearophile
Map and Spawn don't mix?
If I do:
auto tasks = new Tid[numberOfTasks] ;
foreach ( i ; 0 .. numberOfTasks ) { tasks[i] = spawn ( partialSum ,
thisTid , i , sliceSize , delta ) ; }
everything workls as desired, I get parallelism and appropriate scaling.
However if I try:
auto tasks = map ! ( ( i ) { return spawn ( partialSum , thisTid , i ,
sliceSize , delta ) ; } ) ( iota ( numberOfTasks ) ) ;
the code runs but everything is serialized, no parallelism, no speed up.
I would say this is a bug, but perhaps it is a consequence of the way map works?
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: Function literals and lambda functions
Russel Winder rus...@russel.org.uk wrote:
So why does:
reduce ! ( function double ( double a , double b ) { return a +
b ; } ) ( 0.0 , outputData )
fail? It implies that a function literal and a lambda are significantly
different things as far as the compiler is concerned.
Well, they are. One is a delegate literal, the other a function literal.
Delegates may be closures, functions may not.
That said, the above looks like it should work, and I'm not sure why it
doesn't.
--
Simen
Re: Haskell infix syntax
On Mar 7, 11 00:18, bearophile wrote:
Haskell is full of function calls, so the Haskell designers have used/invented
several different ways to avoid some parenthesys in the code.
From what I've seen if you remove some parenthesis well, in the right places,
the resulting code is less noisy, more readable, and it has less chances to
contain a bug (because syntax noise is a good place for bugs to hide).
One of the ways used to remove some parenthesys is a standard syntax that's
optionally usable on any dyadic function (function with two arguments):
sum a b = a + b
sum 1 5 == 1 `sum` 5
The `name` syntax is just a different way to call a regular function with two
arguments.
In Haskell there is also a way to assign an arbitrary precedence and
associativity to such infix operators, but some Haskell programmers argue that
too much syntax sugar gives troubles (
http://www.haskell.org/haskellwiki/Use_of_infix_operators ).
In D the back tick has a different meaning, and even if in D you use a
different syntax, like just a $ prefix, I don't know how much good this syntax
is for D:
int sum(int x, int y) { return x + y; }
int s = sum(1, sum(5, sum(6, sum(10, 30;
Equals to (associativity of $ is fixed like this):
int s = 1 $sum 5 $sum 6 $sum 10 $sum 30;
So I think it's not worth adding to D.
Bye,
bearophile
If we had UFCS this could be written as,
int s = 1.sum(5.sum(6.sum(10.sum(30;
or, knowing sum is associative,
int s = 1.sum(5).sum(6).sum(10).sum(30);
Re: Function literals and lambda functions
On Mar 7, 11 00:45, Simen kjaeraas wrote:
Russel Winder rus...@russel.org.uk wrote:
So why does:
reduce ! ( function double ( double a , double b ) { return a + b ; }
) ( 0.0 , outputData )
fail? It implies that a function literal and a lambda are significantly
different things as far as the compiler is concerned.
Well, they are. One is a delegate literal, the other a function literal.
Delegates may be closures, functions may not.
That said, the above looks like it should work, and I'm not sure why it
doesn't.
Probably unaryFun and binaryFun should accept function pointers as well.
Re: D3 plans
On 22/02/2011 15:00, phobophile wrote: A legitimate question - where are the D3 plans? Any language not in active development (no don't mean phobos, not toolchain) is dead. snip And D is in active development, in the form of fixing bugs and clearing up spec issues, slow as the progress may be. Stewart.
Using Maps with Tuples.
I am wondering if this is a bug to be reported or (more likely) I have
just done the wrong thing.
The statements:
auto inputData = new Tuple ! ( int , int , double ) [ numberOfTasks ] ;
foreach ( i ; 0 .. numberOfTasks ) { inputData[i] = tuple ( i , cast (
int ) ( sliceSize ) , cast ( double ) ( delta ) ) ; }
are in a piece of code that works exactly as expected. If I replace
this with:
auto inputData = map ! ( ( i ) { return tuple ( i , cast ( int ) (
sliceSize ) , cast ( double ) ( delta ) ) ; } ) ( iota ( numberOfTasks ) ) ;
then I get:
pi_d2_sequentialMap.d(40): Error: function
std.algorithm.Map!(partialSum,Map!(__dgliteral1,Iota!(int,uint))).Map.back
cannot get frame pointer to execute
pi_d2_sequentialMap.d(40): Error: function
std.algorithm.Map!(partialSum,Map!(__dgliteral1,Iota!(int,uint))).Map.front
cannot get frame pointer to execute
pi_d2_sequentialMap.d(40): Error: function
std.algorithm.Map!(partialSum,Map!(__dgliteral1,Iota!(int,uint))).Map.opIndex
cannot get frame pointer to execute
/home/users/russel/lib.Linux.x86_64/DMD2/bin/../../src/phobos/std/algorithm.d(187):
Error: function
std.algorithm.Map!(partialSum,Map!(__dgliteral1,Iota!(int,uint))).Map.opSlice
cannot get frame pointer to execute
which tells me which line is problematic, but doesn't give me a real
clue as to what is wrong.
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: Haskell infix syntax
KennyTM~: If we had UFCS this could be written as, UFCS is a huge hack that I hope to never see in D :-) Compared to it, the bad-looking $infix syntax I've just shown is tidy and safe. Bye, bearophile
Re: Function literals and lambda functions
Russel Winder rus...@russel.org.uk wrote: That said, the above looks like it should work, and I'm not sure why it doesn't. Obviously (now :-) because the context requires a delegate not a function -- it is just that the error message doesn't say that in terms that don't relate to the code they relate to the realization within the compiler. Yeah, but reduce should accept a function, not just a delegate. Is this use of the term delegate consistent with the C# idea of delegate? It certainly is not consistent with the use in Groovy and other dynamic languages. There's been some discussion of that before, but I cannot remember whence the term comes. Basically, it it chosen because it's a function pointer with a context passed alongside it, and that's no different for a pointer-to-member-function or a closure. And to illustrate the latter: The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said Master, I have heard that objects are a very good thing - is this true? Qc Na looked pityingly at his student and replied, Foolish pupil - objects are merely a poor man's closures. Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire Lambda: The Ultimate... series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress. On his next walk with Qc Na, Anton attempted to impress his master by saying Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures. Qc Na responded by hitting Anton with his stick, saying When will you learn? Closures are a poor man's object. At that moment, Anton became enlightened. -- Anton van Straaten -- Simen
Re: The .outer property
On 05/03/2011 12:11, Iain Buclaw wrote:
Is this behaviour correct? Should it even be legal to blindly allow access to
members/fields via the .outer context pointer (that may not even be there as
shown in this instance)?
class Outer
{
int w = 3;
void method()
{
int x = 4;
new class Object
{
this()
{
assert(w == 3); // Passes
//assert(x == 4); // Passes
assert(this.outer.w == 3); // Fails if above is uncommented
snip
There's clearly a bug at work here. It seems that there's a clash between two context
pointers: this and the enclosing function.
The compiler should either distinguish between the two or reject the code.
I'll investigate.
Stewart.
Re: Haskell infix syntax
bearophile: UFCS is a huge hack that I hope to never see in D :-) How is it a hack? I can understand there being implementation problems that can make it undesirable to add, but calling it hack? It's one of the most elegant syntax proposals I've ever seen! It unifies objects and other functions in syntax. It improves encapsulation by giving full support to non-member functions. It improves modularity for the same reason. With ufcs, there'd be no desire to add useless members due to object syntax. Everything is equal - easy extensibility, better protection, cleaner interfaces. It's the opposite of a hack.
Re: Haskell infix syntax
bearophile bearophileh...@lycos.com wrote:
So I think it's not worth adding to D.
But if you don't agree... talk.
This is basically already possible in D:
struct InfixOperator( alias fn ) {
auto opBinaryRight( string op : /, T )( T lhs ) {
struct crazy {
T value;
auto opBinary( string op : /, U )( U rhs ) {
return fn( rhs, value );
}
}
return crazy(lhs);
}
}
@property auto _( alias fn )( ) {
return InfixOperator!fn( );
}
T add( T )( T a, T b ) {
return a + b;
}
unittest {
assert( 2 /_!add/ 3 == 5 );
}
--
Simen
Re: Using map instead of iteration
Russel Winder:
Perhaps this needs review. All modern language now have this as an
integral way of describing a sequence of values.
We have discussed about this not too much time ago. See the enhancement request:
http://d.puremagic.com/issues/show_bug.cgi?id=5395
D language design is too much un-orthogonal about this, and I'd like to see
this situation improved.
Currently there are several separated syntaxes and means to specify an interval:
1) foreach interval syntax, no stride allowed and the interval is open on the
right:
foreach (i; 0 .. 100)
2) Using iota, a badly named range, for intervals open on the right, it
supports an optional stride:
foreach (i; iota(100))
But empty intervals have different semantics. This runs with no errors, the
foreach doesn't loop:
void main() {
foreach (i; 0 .. -1) {}
}
While this raises an exception (Enforcement failed):
import std.range;
void main() {
foreach (i; iota(0, -1)) {}
}
3) The switch range syntax, it uses two dots still, it's closed on the right:
import std.range;
void main() {
char c = 'z';
bool good;
switch (c) {
case 'a': .. case 'z':
good = true;
break;
default:
good = false;
break;
}
assert(good);
}
4) Array slice syntax, it allows empty intervals, and it's open on the right,
it uses two dots still (and it's not saturating as the Python one, so you must
be careful with the values of your extrema):
array[1 .. 100]
5) User-defined slice syntax gets converted in a pair of size_t values, instead
of something like a iota():
int opSlice(size_t x, size_t y);
I'd like built-in first-class interval syntax, to remove some of those special
cases. opSlice() may return a value that's a slice, the foreach special
interval syntax may be just removed, just as the switch interval syntax. The
iota() needs to behave like a slice when it's empty, and not produce an error.
Bye,
bearophile
Re: Haskell infix syntax
Simen kjaeraas simen.kja...@gmail.com wrote: This is basically already possible in D: Please do note that this was intended more as a challenge to myself than as a legitimate Good Idea. -- Simen
Re: Naming convention in Phobos
Jonathan M Davis Wrote: On Sunday 06 March 2011 02:59:25 Jim wrote: Okay, so there's a discussion about identifier names in the proposed std.path replacement -- should they be abbreviated or not? Should we perhaps seek to have a consistent naming convention for all identifier names in Phobos? Some of the potential benefits: Legibility, understandability and clarity (reduce ambiguity). Ease in finding a suitable function/class by name. Knowing if it's a cheap or costly function call. Aesthetics and professional appearance. Some properties that I can think of for discussion: Abbreviation (and if so, what to abbreviate and how much)? Preference of commonly used terms in other languages, contexts? Use of get and set prefixes or not (getName() or simply name())? Explicit use of a prefix (example: calc or calculate) for costly operations? Naming of function and template arguments? Uppercase, lowercase, camelcase, underscore in multi-word names? All caps for constants, or different appearance for different types (types, functions, arguments, constants...). What about acronyms: TCP, Tcp? Are there other concerns? The general naming convention as far as variable names go is camelcased with the name starting with a lower case letter - this includes constants. Most of Phobos follows this, and the parts that haven't been have been moving towards it. There are likely to be a few exceptions, but on the whole, that's how it's supposed to be. Type names are the same, except they start with an upper case letter (this includes enum names - the enum values are capitalized the same as any other variables however). That's the way it has been, and that's the way that it's pretty much guaranteed to stay. Generally speaking, we want descriptive names, and I think that it's safe to say that we don't want overly long names, so if we can have descriptive but short names, that's generally best. get and set prefixes are likely to be rare, because most of such functions will be properties, and properties will normally have nouns for names and won't use get or set, but I don't think that we want to say that we'll _never_ have function names prefixed with get or set. Normally, we won't, but it's going to be very situation-dependent. Now, as for the rest of it, I don't really want to get into a big discussion of the best way to name everything. It's far too context-dependent and very quickly turns towards bike shedding. I think that it's appropriate for anyone who's developing a module for Phobos to come up with names that they think are reasonable and which follow the very basic naming conventions that we follow, and then have names adjusted as needed during the review process. I really don't think that we're going to get much of value by having a big discussion over general naming conventions. It seems to me like it's just going to be a classic situation for bike shedding and generally useless discussion. What we've been doing generally works just fine. - Jonathan M Davis All right, thanks for the courteous reply. Considering the other comments in this thread I think there isn't much interest in working out or agreeing on a few good principles or guidelines for naming identifiers in Phobos. Otherwise, even if we could only agree on a few of them, they could be written down somewhere, should anyone someday be inclined to join the development.
Re: Haskell infix syntax
Simen kjaeraas:
This is basically already possible in D:
I suggest you to stop using the single underscore as identifier.
unittest {
assert( 2 /_!add/ 3 == 5 );
}
OK. Now let's go back to Haskell :-)
Thank you for your answer,
bye,
bearophile
Re: The .outer property
On 05/03/2011 12:11, Iain Buclaw wrote: Is this behaviour correct? Should it even be legal to blindly allow access to members/fields via the .outer context pointer (that may not even be there as shown in this instance)? snip Bug filed: http://d.puremagic.com/issues/show_bug.cgi?id=5711 Stewart.
Re: Haskell infix syntax
bearophile bearophile napisał:
Haskell is full of function calls, so the Haskell designers have
used/invented several different ways to avoid some parenthesys in the code.
From what I've seen if you remove some parenthesis well, in the right places,
the resulting code is less noisy, more readable, and it has less chances to
contain a bug (because syntax noise is a good place for bugs to hide).
One of the ways used to remove some parenthesys is a standard syntax that's
optionally usable on any dyadic function (function with two arguments):
sum a b = a + b
sum 1 5 == 1 `sum` 5
The `name` syntax is just a different way to call a regular function with two
arguments.
In Haskell there is also a way to assign an arbitrary precedence and
associativity to such infix operators, but some Haskell programmers argue
that too much syntax sugar gives troubles (
http://www.haskell.org/haskellwiki/Use_of_infix_operators ).
In D the back tick has a different meaning, and even if in D you use a
different syntax, like just a $ prefix, I don't know how much good this
syntax is for D:
int sum(int x, int y) { return x + y; }
int s = sum(1, sum(5, sum(6, sum(10, 30;
Equals to (associativity of $ is fixed like this):
int s = 1 $sum 5 $sum 6 $sum 10 $sum 30;
So I think it's not worth adding to D.
I vaguely recall someone mentioned infixablility by naming convention.
int _add_(int x, int y);
int s = 1 _add_ 5 _add_ 10;
As a feature of its own, it's just sugar. But if introducing infix operators
were contingent on banishing classic operator overloading, then it is
worthwhile.
--
Tomek
Re: Proposal for std.path replacement
Lars T. Kyllingstad Wrote: On Sat, 05 Mar 2011 14:33:07 -0800, Jonathan M Davis wrote: On Saturday 05 March 2011 08:32:55 Lars T. Kyllingstad wrote: On Fri, 04 Mar 2011 08:14:44 -0500, Nick Sabalausky wrote: Lars T. Kyllingstad public@kyllingen.NOSPAMnet wrote in message news:ikofkc$322$1...@digitalmars.com... As mentioned in the std.path.getName(): Screwy by design? thread, I started working on a rewrite of std.path a long time ago, but I got sidetracked by other things. The recent discussion got me working on it again, and it turned out there wasn't that much left to be done. So here it is, please comment: http://kyllingen.net/code/ltk/doc/path.html https://github.com/kyllingstad/ltk/blob/master/ltk/path.d I don't want to jinx it, but there seems to be a lot of agreement in this thread. Seriously, how often does that happen around here? :) Not too often, so I take it as a good sign that I'm onto something. ;) The only disagreement seems to be about the naming, so let's have a round of voting. Here are a few alternatives for each function. Please say which ones you prefer. * dirSeparator, dirSep, sep dirSep and pathSep. Having Separator in the name is unnecessarily long. * currentDirSymbol, currentDirSym, curDirSymbol currDirSym and parentDirSym (and currDirSymbol and parentDirSymbol if abbreviating both current and symbol is too much). Shorter but still quite clear. I would _definitely_ use two r's when abbreviating current though, since current has two r's. I confess that it' a major pet peeve of mine when I see current abbreviate with one r. It feels like it's being spelled wrong, since current has two r's. * basename, baseName, filename, fileName baseName * dirname, dirName, directory, getDir, getDirName dirName * drivename, driveName, drive, getDrive, getDriveName driveLetter would probably be better actually - though it _could_ be more than one letter if someone has an insane number of drives (it's usually referred to as a drive letter though). Barring that, drive would be fine (as long as it's a property). Interestingly, it seems drive names are actually restricted to one letter. See the last paragraph of this section: http://en.wikipedia.org/wiki/Drive_letter#Common_assignments -Lars Drive names in AmigaOS are longer by default iirc. Anyway, Microsoft might someday depart from the idea of drive letters. Whether they might support longer names or just abandon drive identifiers altogether is of course insolubly unknown, but I think names are at least a more general concept than letters (so as not to lock ourselves in with a passing coherence).
Re: Naming convention in Phobos
Jim wrote: Jonathan M Davis Wrote: On Sunday 06 March 2011 02:59:25 Jim wrote: Okay, so there's a discussion about identifier names in the proposed std.path replacement -- should they be abbreviated or not? Should we perhaps seek to have a consistent naming convention for all identifier names in Phobos? Some of the potential benefits: • Legibility, understandability and clarity (reduce ambiguity). • Ease in finding a suitable function/class by name. • Knowing if it's a cheap or costly function call. • Aesthetics and professional appearance. Some properties that I can think of for discussion: • Abbreviation (and if so, what to abbreviate and how much)? • Preference of commonly used terms in other languages, contexts? • Use of get and set prefixes or not (getName() or simply name())? • Explicit use of a prefix (example: calc or calculate) for costly operations? • Naming of function and template arguments? • Uppercase, lowercase, camelcase, underscore in multi-word names? All caps for constants, or different appearance for different types (types, functions, arguments, constants...). What about acronyms: TCP, Tcp? Are there other concerns? The general naming convention as far as variable names go is camelcased with the name starting with a lower case letter - this includes constants. Most of Phobos follows this, and the parts that haven't been have been moving towards it. There are likely to be a few exceptions, but on the whole, that's how it's supposed to be. Type names are the same, except they start with an upper case letter (this includes enum names - the enum values are capitalized the same as any other variables however). That's the way it has been, and that's the way that it's pretty much guaranteed to stay. Generally speaking, we want descriptive names, and I think that it's safe to say that we don't want overly long names, so if we can have descriptive but short names, that's generally best. get and set prefixes are likely to be rare, because most of such functions will be properties, and properties will normally have nouns for names and won't use get or set, but I don't think that we want to say that we'll _never_ have function names prefixed with get or set. Normally, we won't, but it's going to be very situation-dependent. Now, as for the rest of it, I don't really want to get into a big discussion of the best way to name everything. It's far too context-dependent and very quickly turns towards bike shedding. I think that it's appropriate for anyone who's developing a module for Phobos to come up with names that they think are reasonable and which follow the very basic naming conventions that we follow, and then have names adjusted as needed during the review process. I really don't think that we're going to get much of value by having a big discussion over general naming conventions. It seems to me like it's just going to be a classic situation for bike shedding and generally useless discussion. What we've been doing generally works just fine. - Jonathan M Davis All right, thanks for the courteous reply. Considering the other comments in this thread I think there isn't much interest in working out or agreeing on a few good principles or guidelines for naming identifiers in Phobos. Otherwise, even if we could only agree on a few of them, they could be written down somewhere, should anyone someday be inclined to join the development. All future modules will undergo a review process which will prevent the worst naming examples. We will need to initiate a review of existing modules at some point. Until that's completed, it would seem to be a bit counterproductive to publish a list of rules that 80% of Phobos modules break... But in general, I agree with you.
Re: Map and Spawn don't mix?
On 3/6/11 10:44 AM, Russel Winder wrote:
If I do:
auto tasks = new Tid[numberOfTasks] ;
foreach ( i ; 0 .. numberOfTasks ) { tasks[i] = spawn ( partialSum ,
thisTid , i , sliceSize , delta ) ; }
everything workls as desired, I get parallelism and appropriate scaling.
However if I try:
auto tasks = map ! ( ( i ) { return spawn ( partialSum , thisTid , i ,
sliceSize , delta ) ; } ) ( iota ( numberOfTasks ) ) ;
the code runs but everything is serialized, no parallelism, no speed up.
I would say this is a bug, but perhaps it is a consequence of the way map works?
I doubt the code ever runs - map is lazy.
Andrei
Re: Function literals and lambda functions
On 3/6/11 11:25 AM, Simen kjaeraas wrote: Russel Winder rus...@russel.org.uk wrote: That said, the above looks like it should work, and I'm not sure why it doesn't. Obviously (now :-) because the context requires a delegate not a function -- it is just that the error message doesn't say that in terms that don't relate to the code they relate to the realization within the compiler. Yeah, but reduce should accept a function, not just a delegate. The limitations related to frame pointers should be handled as important bugs. D has innovated a lot in this regard, and I believe that the full potential has yet to be attained. Andrei
Re: Naming convention in Phobos
On 03/06/2011 04:54 PM, foobar wrote: Andrei Alexandrescu Wrote: On 3/6/11 9:27 AM, foobar wrote: Nick Sabalausky Wrote: Jimbitcir...@yahoo.com wrote in message news:ikvped$1o35$1...@digitalmars.com... Okay, so there's a discussion about identifier names in the proposed std.path replacement -- should they be abbreviated or not? Should we perhaps seek to have a consistent naming convention for all identifier names in Phobos? Some of the potential benefits: • Legibility, understandability and clarity (reduce ambiguity). • Ease in finding a suitable function/class by name. • Knowing if it's a cheap or costly function call. • Aesthetics and professional appearance. Some properties that I can think of for discussion: • Abbreviation (and if so, what to abbreviate and how much)? • Preference of commonly used terms in other languages, contexts? • Use of get and set prefixes or not (getName() or simply name())? • Explicit use of a prefix (example: calc or calculate) for costly operations? • Naming of function and template arguments? • Uppercase, lowercase, camelcase, underscore in multi-word names? All caps for constants, or different appearance for different types (types, functions, arguments, constants...). What about acronyms: TCP, Tcp? Are there other concerns? I think that every individual variable, function and type in Phobos should use the naming convention of whatever random language the author happened to be thinking of when they wrote it. That way Phobos won't seem messy. Plus, the lack of any sensible rules would make it super-easy to remember all the different spellings, punctuations and capitalizations. I would also add to the above excellent point that in order to prevent unworthy people of programming in the holly You have a typo there. Andrei Well than I must be unworthy of the D community. I must flee before you come chasing me with pitchforks... ...or anathems Denis -- _ vita es estrany spir.wikidot.com
Re: Proposal for std.path replacement
On 03/06/2011 04:41 PM, Rainer Schuetze wrote: Lars T. Kyllingstad wrote: On Sun, 06 Mar 2011 09:37:15 +0100, Rainer Schuetze wrote: What about file.? I tried it on NTFS, but trailing '.' seems to always be cut off. Is it possible to create such a file on unix systems? If yes, you won't be able to recreate it from the result of basename() and extension(). Good point. I don't know if there is any kind of precedent here. What do others think? Maybe special casing similar to the hidden files starting with '.': basename(file.) -- file. extension(file.) -- I agrre, and this is probably the correct solution: if there is nothing after the dot, then it's not an extension separator, thus it's part of the baseName (just like if there is nothing before the dot). Denis -- _ vita es estrany spir.wikidot.com
Re: Function literals and lambda functions
On 6/03/11 2:03 PM, Russel Winder wrote: PS If you ask why not: reduce ! ( a+b ) ( 0.0 , outputData ) I find this somehow unacceptable. It's the string, its not a function. Fine, my problem, but that still leaves the above. You probably know this already, but just in case... The string is converted into a function at compile time, so if you were scared of the possible performance hit of having to parse the string at runtime, then you can rest assured that it is as fast as supplying a normal function. On the other hand, if you just don't like the appearance of a string as a function in source code then, yah, I agree. It does seem a little wrong, although you get used to it.
Re: Naming convention in Phobos
Simen kjaeraas simen.kja...@gmail.com wrote in message news:op.vrxix902vxi10f@biotronic-laptop... foobar f...@bar.com wrote: I would also add to the above excellent point that in order to prevent unworthy people of programming in the holly You have a typo there. Andrei Well than I must be unworthy of the D community. I must flee before you come chasing me with pitchforks... A witch! May we burn it? Such a polite way of inciting a witch burning :)
Re: Proposal for std.path replacement
On Sun, 06 Mar 2011 10:37:15 +0200, Rainer Schuetze r.sagita...@gmx.de wrote: What about file.? I tried it on NTFS, but trailing '.' seems to always be cut off. It's possible to create files and directories with one trailing dot on Windows/NTFS. FAR Manager allows doing this, for example. I'm not sure if the implementation does anything special to achieve this, but it's not impossible. (Ditto with leading and trailing spaces.) By the way, not sure if it's been mentioned in this discussion but: .exe is an executable file with no name. It's perfectly valid. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: Proposal for std.path replacement
On Sun, 06 Mar 2011 09:29:27 -0600, Andrei Alexandrescu wrote: On 3/6/11 6:31 AM, Lars T. Kyllingstad wrote: In summary, it seems currentDirSymbol, baseName, dirName and driveName are clear winners. Less clear, but still voted for by the majority, are extension and stripExtension. It is a tie between dirSep and dirSeparator. Below are the votes I counted. And before you say hey, I didn't know we could make suggestions of our own, or why did that guy get several votes?, this was by no means a formal vote. It was just trying to get a feel for people's preferences. Before the module gets accepted into Phobos there will have to be a formal review process, so there is still a lot of opportunity to fight over naming. :) I think whatever you choose will not please everybody, so just choose something and stick with it. Regarding all the extension naming stuff, I suggest you go with the suffix nomenclature which is more general and applicable to all OSs. I don't agree. A suffix can be anything, and we already have functions in std.algorithm, std.array and std.string to deal with the general case. Like it or not, filename extensions are still the main method for conveying file type information on Windows (and even to some extent on Linux and OSX). I think that's a good reason to include support for manipulating extensions in std.path. Regarding semantics, consistently strip the trailing slash. It is unequivocally the best semantics (and incidentally or not it's what Unix's dirname and basename do). If rsync et al need it, they can always look for it in the initial parameter. The reality of the matter is that you will never be able to accommodate all use cases there are with maximum convenience. I agree, and that's how I've done it. You may want to prepare this for review after April 1st, when the review for std.parallelism ends. There is good signal in the exchange so far, but from here on this discussion could go on forever and shift focus away from std.parallelism. Absolutely. This was only intended as informal discussion, and not as a start on the formal review. -Lars
Re: Proposal for std.path replacement
On 3/6/11, Vladimir Panteleev vladi...@thecybershadow.net wrote: .exe is an executable file with no name. It's perfectly valid. Although for some reason Explorer never lets you do that. Well, I have a hotkey for creating filenames so I just let autohotkey create the file such as .file. Doing it in explorer via rename gets: You must type a file name.
Re: Proposal for std.path replacement
Jérôme M. Berger jeber...@free.fr wrote in message news:il0f04$2ts8$1...@digitalmars.com... This does not make sense because there is no way to tell whether foo/bar is intended as a file name or a dir name. IMO the only sensible thing to do is to split on the last path separator: everything to the right is the base name (or everything if there is no separator) and everything to the left is the dir name. This has the two very important advantages: - It is a simple rule, so is easy to remember;` But it doesn't have simple consequences. If I'm trying to refer to a particular directory there's a good chance it could be either /foo/bar or /foo/bar/ (and the latter is *not* typically thought of as a shorthand for /foo/bar/.). Those are conceptually the *exact same thing*, but with the last slash rule you suggest, they have wildy different effects when passed to certain std.path functions. Most notably, if it's a path with a trailing slash, then dirName **no longer returns the directory that *contains* the element specified**. It just returns the element itself *instead* of its containing directory. So, since certain functions would have notably different effects with and without a trailing slash, and the trailing slash may or may not have been given (since the two styles are typically thought of as interchangable), every time you call a std.path functions the last slash rule would force you to go through these steps: 1. Remember if the function you're using is one that's affected. 2. If so, decide which semantics you want. 3. Detect if the trailing-slashness of your string matches the semantics you want. Which may, in fact, be impossible: If the semantics you desire dictate a trailing slash on directories, and your string lacks a trailing slash then the *only* way to proceed correctly is to know whether it's intended to be a file or a directory, and you don't always know. 4. Coerce your string to match the desired semantics, if possible. 5. Finally call the dammed function. - It does not need the path to exists and it does not need to know whether the path is intended as a file or dir. As I described above, it will sometimes need to know. Alternatively, the current behavior of Lars's proposed std.path is, to the human mind, an equally simple rule and therefore equally simple to remember: That last element is the baseName and all the elements before it are the dirName. In contrast to the last slash rule, this last element rule behaves exactly the same regardless of whether a trailing slash was appended or omitted and *actually* never needs to know if the path is intended as a file or dir. So the five steps above get condensed down to one: 1. Just call the dammed function. I'll admit, the last element behavior of Lars's proposed std.path did raise a small red flag to me at first. But the more I think about it, the more I think it's the best way to go.
Re: Proposal for std.path replacement
Vladimir Panteleev vladi...@thecybershadow.net wrote in message news:op.vrxw6dmltuz...@cybershadow.mshome.net... On Sun, 06 Mar 2011 10:37:15 +0200, Rainer Schuetze r.sagita...@gmx.de wrote: What about file.? I tried it on NTFS, but trailing '.' seems to always be cut off. It's possible to create files and directories with one trailing dot on Windows/NTFS. FAR Manager allows doing this, for example. I'm not sure if the implementation does anything special to achieve this, but it's not impossible. (Ditto with leading and trailing spaces.) By the way, not sure if it's been mentioned in this discussion but: .exe is an executable file with no name. It's perfectly valid. It ain't valid when optlink creates it ;)
Re: Proposal for std.path replacement
Lars T. Kyllingstad public@kyllingen.NOSPAMnet wrote in message news:il09fp$2h5d$1...@digitalmars.com... On Sun, 06 Mar 2011 15:54:19 +0100, spir wrote: What about extending the notion of 'device' (see other post) to cover 'http://' and ftp://;? Would it be complicated? I don't think std.path should handle general URIs. It should only have to deal with the kind of paths you can pass to the functions in std.file and std.stdio. If std.path doesn't handle uri's, then we'd need a whole other set of functions for dealing with uris. And at least a few of the functions would overlap. And then people who want to be able to handle both files and uris will want functions that will seamlessly handle either. So I think it really would be best to just bite the bullet and have std.path handle uri's. That said, I'm not sure this would be necessary for round 1 of the new std.path. Could just be added later.
Re: Proposal for std.path replacement
On Sunday 06 March 2011 13:49:59 Nick Sabalausky wrote: Lars T. Kyllingstad public@kyllingen.NOSPAMnet wrote in message news:il09fp$2h5d$1...@digitalmars.com... On Sun, 06 Mar 2011 15:54:19 +0100, spir wrote: What about extending the notion of 'device' (see other post) to cover 'http://' and ftp://;? Would it be complicated? I don't think std.path should handle general URIs. It should only have to deal with the kind of paths you can pass to the functions in std.file and std.stdio. If std.path doesn't handle uri's, then we'd need a whole other set of functions for dealing with uris. And at least a few of the functions would overlap. And then people who want to be able to handle both files and uris will want functions that will seamlessly handle either. So I think it really would be best to just bite the bullet and have std.path handle uri's. That said, I'm not sure this would be necessary for round 1 of the new std.path. Could just be added later. We do have std.uri, though it's pretty bare-boned at the moment. - Jonathan M Davis
Re: Function literals and lambda functions
Sun, 06 Mar 2011 20:24:12 +, Peter Alexander wrote: On 6/03/11 2:03 PM, Russel Winder wrote: PS If you ask why not: reduce ! ( a+b ) ( 0.0 , outputData ) I find this somehow unacceptable. It's the string, its not a function. Fine, my problem, but that still leaves the above. You probably know this already, but just in case... The string is converted into a function at compile time, so if you were scared of the possible performance hit of having to parse the string at runtime, then you can rest assured that it is as fast as supplying a normal function. On the other hand, if you just don't like the appearance of a string as a function in source code then, yah, I agree. It does seem a little wrong, although you get used to it. It also generates a bit of redundant code for each template instantiation. No solution for this has been proposed afaik. It's a deal breaker in embedded programming.
Re: Function literals and lambda functions
retard: It also generates a bit of redundant code for each template instantiation. No solution for this has been proposed afaik. From a recent answer, I think Walter hopes in a magic solution for this bunch of problems. In past I have shown some possible attacks against this bunch of problems: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=108136 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=108275 My theory is that you can't ask the compiler to magically solve this problem, or to produce a ton of templates and them remove most of them and most of the code duplication. A more practical approach is probably needed, and this means using several different ideas to avoid creating templates, etc. One idea: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=126655 It's a deal breaker in embedded programming. Don't worry, I don't see people using D for embedded programming soon. D is not designed for this purposes. Today there are no good languages for embedded programming. C is used out of desperation because there is almost nothing else for it. On the other hand embedded programming is slowly changing, the available RAM is growing and sometimes even 32 bit CPUs are used (but smaller CPUs are hugely more common still). Thank you retard. Bye, bearophile
Re: Haskell infix syntax
On Sunday 06 March 2011 09:34:07 Adam D. Ruppe wrote: bearophile: UFCS is a huge hack that I hope to never see in D :-) How is it a hack? I can understand there being implementation problems that can make it undesirable to add, but calling it hack? It's one of the most elegant syntax proposals I've ever seen! It unifies objects and other functions in syntax. It improves encapsulation by giving full support to non-member functions. It improves modularity for the same reason. With ufcs, there'd be no desire to add useless members due to object syntax. Everything is equal - easy extensibility, better protection, cleaner interfaces. It's the opposite of a hack. It is _not_ a hack. Whether it's desirable or not is another matter, but it is _not_ a hack. And really, the term hack is very imprecise and often subjective. It's the sort of accusation that pretty much kills any legitimate debate. It's generally unsupportable and subjective, so it adds nothing to the debate, but it has such a stink about it that it tends to make people avoid whatever was declared to be a hack. Sure, you still have lots of parens with UFCS, but you _do_ get the argument order that Bearophile was looking for. And while I've generally found the idea of using UFCS with primitives to be pointless, this is actually an example where it's _useful_ with primitives. No, UFCS is not a hack. Its implementation has enough problems due to ambiguities and the like that it may never make it into the language even if pretty much everyone would _like_ it in the language, but it's not a hack. - Jonathan M Davis P.S. Entertainingly enough, www.merriam-webster.com's definition for hack doesn't make it look bad at all: a usually creative solution to a computer hardware or programming problem or limitation It makes me wonder if the usage of the word (and thus its common meaning) has shifted over time or if the poor non-techy, dictionary folk just plain got it wrong. The hacker's dictionary definition makes it look more like the typical usage, but even it is a bit of a mixed bag in that respect: 1. /n./ Originally, a quick job that produces what is needed, but not well. 2. /n./ An incredibly good, and perhaps very time-consuming, piece of work that produces exactly what is needed.
Re: Haskell infix syntax
On Sunday 06 March 2011 10:03:05 Tomek Sowiński wrote:
bearophile bearophile napisał:
Haskell is full of function calls, so the Haskell designers have
used/invented several different ways to avoid some parenthesys in the
code.
From what I've seen if you remove some parenthesis well, in the right
places, the resulting code is less noisy, more readable, and it has less
chances to contain a bug (because syntax noise is a good place for bugs
to hide).
One of the ways used to remove some parenthesys is a standard syntax
that's optionally usable on any dyadic function (function with two
arguments):
sum a b = a + b
sum 1 5 == 1 `sum` 5
The `name` syntax is just a different way to call a regular function with
two arguments.
In Haskell there is also a way to assign an arbitrary precedence and
associativity to such infix operators, but some Haskell programmers
argue that too much syntax sugar gives troubles (
http://www.haskell.org/haskellwiki/Use_of_infix_operators ).
In D the back tick has a different meaning, and even if in D you use a
different syntax, like just a $ prefix, I don't know how much good this
syntax is for D:
int sum(int x, int y) { return x + y; }
int s = sum(1, sum(5, sum(6, sum(10, 30;
Equals to (associativity of $ is fixed like this):
int s = 1 $sum 5 $sum 6 $sum 10 $sum 30;
So I think it's not worth adding to D.
I vaguely recall someone mentioned infixablility by naming convention.
int _add_(int x, int y);
int s = 1 _add_ 5 _add_ 10;
As a feature of its own, it's just sugar. But if introducing infix
operators were contingent on banishing classic operator overloading, then
it is worthwhile.
LOL. And _what_ benefit would banishing classic operator overloading have? A
function named add could be abused in _exactly_ the same ways that + can be.
The main benefit that infix syntax would provide would be if you had a variety
of
mathematical functions beyond what the built in operators give you, and you
want
to be able to treat them the same way. Whether classic operator overloading
exists or not is irrelevant.
Regardless, I don't think that adding infix syntax to the language is worth it.
D
is already pretty complicated and _definitely_ more complicated than most
languages out there. One of the major complaints of C++ is how complicated it
is. We don't want to be adding extra complexity to the language without the
benefit outweighing that complexity, and I don't think that it's at all clear
that it does in this case. As as KennyTM~ pointed out, if UFCS is ever
implemented, it gives you most of the benefit of this anyway, and there are
already a lot of people around here interested in UFCS. So, I find it _far_
more
likely that UFCS gets implemented than an infix function call syntax.
- Jonathan M Davis
Re: Function literals and lambda functions
On Sunday 06 March 2011 06:03:31 Russel Winder wrote:
OK, this one surprised me, all that remains is for me to find out why it
shouldn't have done:
reduce ! ( ( a , b ) { return a + b ; } ) ( 0.0 , outputData )
works just fine, but:
reduce ! ( function double ( double a , double b ) { return a + b ;
} ) ( 0.0 , outputData )
results in:
pi_d2_sequentialMap.d(45): Error: function
std.algorithm.reduce!(function double(double a, double b) {
return a + b;
}
).reduce!(double,Map!(partialSum,Tuple!(int,int,double)[])).reduce.__funcl
iteral1 cannot access frame of function
pi_d2_sequentialMap.execute.__funcliteral1 pi_d2_sequentialMap.d(45):
Error: function std.algorithm.reduce!(function double(double a, double b)
{
return a + b;
}
).reduce!(double,Map!(partialSum,Tuple!(int,int,double)[])).reduce.__funcl
iteral1 cannot access frame of function
pi_d2_sequentialMap.execute.__funcliteral1
which I think qualifies for the label incomprehensible. Not to
mention repetitious.
PS If you ask why not:
reduce ! ( a+b ) ( 0.0 , outputData )
I find this somehow unacceptable. It's the string, its not a function.
Fine, my problem, but that still leaves the above.
LOL. Whereas I find reduce!a+b _far_ clearer then having to write out the
whole
lambda function. Sure, there are cases where the string syntax doesn't cut it,
but it's so much shorter and yet still perfectly clear (no extraneous parameter
lists or braces or semicolons...), that I think that it's pretty much always
preferred to actual, in-place lambda functions.
- Jonathan M Davis
Re: Using map instead of iteration
On Sunday 06 March 2011 05:57:12 Simen kjaeraas wrote: You should use std.range.iota(0,numberOfThreads) instead of 0..numberOfThreads. Having a..b return a general interval range has been proposed numerous times, but nothing has been implemented as of yet. I'm sure that part of the problem is the fact that a .. b is also used in slicing, where it does not mean the same thing - that and iota works just fine, and increasingly, Andrei and Walter seem to prefer having stuff in the library rather than the language itself when there's no significant gain to be had by putting it in the language. - Jonathan M Davis
Re: Haskell infix syntax
Jonathan M Davis: And really, the term hack is very imprecise and often subjective. It's the sort of accusation that pretty much kills any legitimate debate. You are right, sorry for using a so subjective term. I will avoid it. Bye, bearophile
Re: Proposal for std.path replacement
On Sunday 06 March 2011 04:31:20 Lars T. Kyllingstad wrote: On Sat, 05 Mar 2011 16:32:55 +, Lars T. Kyllingstad wrote: On Fri, 04 Mar 2011 08:14:44 -0500, Nick Sabalausky wrote: Lars T. Kyllingstad public@kyllingen.NOSPAMnet wrote in message news:ikofkc$322$1...@digitalmars.com... As mentioned in the std.path.getName(): Screwy by design? thread, I started working on a rewrite of std.path a long time ago, but I got sidetracked by other things. The recent discussion got me working on it again, and it turned out there wasn't that much left to be done. So here it is, please comment: http://kyllingen.net/code/ltk/doc/path.html https://github.com/kyllingstad/ltk/blob/master/ltk/path.d I don't want to jinx it, but there seems to be a lot of agreement in this thread. Seriously, how often does that happen around here? :) Not too often, so I take it as a good sign that I'm onto something. ;) The only disagreement seems to be about the naming, so let's have a round of voting. Here are a few alternatives for each function. Please say which ones you prefer. * dirSeparator, dirSep, sep * currentDirSymbol, currentDirSym, curDirSymbol * basename, baseName, filename, fileName * dirname, dirName, directory, getDir, getDirName * drivename, driveName, drive, getDrive, getDriveName * extension, ext, getExt, getExtension * stripExtension, stripExt (The same convention will be used for stripExtension, replaceExtension and defaultExtension.) In summary, it seems currentDirSymbol, baseName, dirName and driveName are clear winners. Less clear, but still voted for by the majority, are extension and stripExtension. It is a tie between dirSep and dirSeparator. Below are the votes I counted. And before you say hey, I didn't know we could make suggestions of our own, or why did that guy get several votes?, this was by no means a formal vote. It was just trying to get a feel for people's preferences. Before the module gets accepted into Phobos there will have to be a formal review process, so there is still a lot of opportunity to fight over naming. :) dirSep: 3 (Nick Sabalausky, spir, Jonathan M. Davis) dirSeparator: 3 (Bekenn, Jim, J Chapman) currDirSym: 1 (Jonathan M. Davis) currDirSymbol: 2 (Nick Sabalausky, Jonathan M. Davis) path.current: 1 (Andrej Mitrovic) currentDirSymbol: 4 (Bekenn, Jim, J Chapman, spir) baseName: 6 (Nick Sabalausky, Bekenn, Jim, J Chapman, spir, Jonathan M. Davis) baseFileName: 1 (Nick Sabalausky) fileName: 1 (spir) basename: 1 (Andrei Alexandrescu) dirName: 6 (Nick Sabalausky, Bekenn, Jim, spir, Jonathan M. Davis, David Nadlinger) directory: 1 (Nick Sabalausky) getDirName: 2 (J Chapman, spir) dirname: 1 (Andrei Alexandrescu) driveName: 4 (Nick Sabalausky, Bekenn, Jim, spir) drive: 2 (Nick Sabalausky, Jonathan M. Davis) getDriveName: 2 (J Chapman, spir) driveLetter: 1 (Jonathan M. Davis) ext: 1 (Nick Sabalausky) extension: 2 (Bekenn, Jim) getExtension: 1 (J Chapman) stripExt: 2 (Nick Sabalausky, Jonathan M. Davis) stripExtension: 3 (Bekenn, Jim, J Chapman) This is a very small sampling of even the folks here on the newsgroup, let alone the D community at large, so I don't think that you can really base all _that_ much off of the votes. Rather, I think that you should pretty much do what Andrei said and pick what you think is best, but now you have some opinions and arguments from other people that you can take into consideration when naming the functions. As Andrei said, you're never going to get everyone to agree anyway. I think that the general guidelines here should be that the names be descriptive but as short as they can reasonably be and still be appropriately descriptive. Names which are not descriptive enough are likely to not be clear enough, but names that are very descriptive but as very long are likely to get very annoying - especially if you have to use them often and/or have to deal with a character limit per line. So, take what has been said into consideration and adjust the names as you think is appropriate. I'm sure that they'll get debated further when you actually put it up for a full review. But naming is arguably _the_ classic bike shedding issue. It matters but not in proportion with the amount of discussion and arguing that it gets, and you'll _never_ get everyone to agree over it. On a side note, any functions that have changed behavior should probably have names which are different from what's currently in std.path. So, for instance, if your basename function has different behavior from the current std.path's basename, you should probably give it a different name (in this case, the obvious solution is baseName - it actually follows Phobos' naming conventions and was the pretty clear favorite in this discussion). Otherwise, you're going to break code when your code gets merged into Phobos. If the behavioral
Re: Proposal for std.path replacement
On 03/06/2011 10:49 PM, Nick Sabalausky wrote: Lars T. Kyllingstadpublic@kyllingen.NOSPAMnet wrote in message news:il09fp$2h5d$1...@digitalmars.com... On Sun, 06 Mar 2011 15:54:19 +0100, spir wrote: What about extending the notion of 'device' (see other post) to cover 'http://' and ftp://;? Would it be complicated? I don't think std.path should handle general URIs. It should only have to deal with the kind of paths you can pass to the functions in std.file and std.stdio. If std.path doesn't handle uri's, then we'd need a whole other set of functions for dealing with uris. And at least a few of the functions would overlap. And then people who want to be able to handle both files and uris will want functions that will seamlessly handle either. So I think it really would be best to just bite the bullet and have std.path handle uri's. That said, I'm not sure this would be necessary for round 1 of the new std.path. Could just be added later. Right, but if there is reasonable probability for such an extension, then we must think at it, so-to-say at design time. Else, various common issues will raise barriers on the way of extension (existing codebase, detail conflicts, refactoring requirements... naming! ;-) (*) Then, once such work is on good way, possibly implementation is no more such a big deal. Or, conversely, we may feel the need for prototyping and trials to construct and/or validate a big picture design. Etc... To sum up: since there is no emergency (-- Andrei's last post), we have a very good base thank to Lars's well-thought job, and there are already a number of people involved in the discussion -- why not? Denis (*) drive name -- ? -- _ vita es estrany spir.wikidot.com
Re: Proposal for std.path replacement
On Sunday 06 March 2011 07:29:27 Andrei Alexandrescu wrote: I think whatever you choose will not please everybody, so just choose something and stick with it. Regarding all the extension naming stuff, I suggest you go with the suffix nomenclature which is more general and applicable to all OSs. I agree with Lars on this one. Everyone knows what an extension is. It's a universal concept even if it's not used as much on non-Windows OSes. There _are_ plenty of programs in *nix which use it internally (likely because it's a lot easier than dealing with mime type) even if they shouldn't. suffix instead of extension or ext would be a lot less clear to most people and add pretty much no benefit. You may want to prepare this for review after April 1st, when the review for std.parallelism ends. There is good signal in the exchange so far, but from here on this discussion could go on forever and shift focus away from std.parallelism. I agree that we've probably gotten as much out of the discussion of std.path as we could reasonably get prior to a full review, so continuing a major discussion in this thread is likely unwarranted. However, are you indicating that we should never have more than one module in review at a time? I see some benefit in spreading them out, on the other hand, if we have multiple modules ready for review, it seems like we could be slowing down progress unnecessarily if we ruled that we could only ever have one module under review at a time. As for std.parallelism, I fear that that is the sort of module which is going to get close examination by a few people and most others will either ignore because they don't really intend to use it or because they fear that it will be too complicated to look at and review (especially if they're not all that well- versed in threading). So, I'm not sure how much of an in-depth examination it's going to get by the group at large. Which reminds me, I still need to go check it out... - Jonathan M Davis
Re: Proposal for std.path replacement
On 03/07/2011 01:44 AM, Jonathan M Davis wrote: I think whatever you choose will not please everybody, so just choose something and stick with it. Regarding all the extension naming stuff, I suggest you go with the suffix nomenclature which is more general and applicable to all OSs. I agree with Lars on this one. Everyone knows what an extension is. It's a universal concept even if it's not used as much on non-Windows OSes. There _are_ plenty of programs in *nix which use it internally (likely because it's a lot easier than dealing with mime type) even if they shouldn't. eg: numerous compilers, programming editors,... ;-) Denis -- _ vita es estrany spir.wikidot.com
Re: Pretty please: Named arguments
(De-lurking; I've been interested in D for a while, but my programming
is almost exclusively in C -- generally C99.)
Does D have the equivalent of C99's designated initializers?
Were I to attempt something like this in C, the code would go something
like this:
int foo(int height, int width);
struct _foo_args {
int height; int width;
};
#define foo(...) \
foo((struct _foo_args){__VA_ARGS__}.height, \
(struct _foo_args){__VA_ARGS__}.width)
at which point each of these calls:
foo(a, b);
foo(.height = a, .width = b);
foo(.width = b, .height = a);
have the same effect.
I'll readily admit this is *not* pretty, and likely more effort than
it's worth, but is will work.
Are D's compile-time operations not capable of something at *least* this
powerful?
--Joel
Re: Proposal for std.path replacement
On Sunday 06 March 2011 16:54:41 spir wrote: On 03/07/2011 01:44 AM, Jonathan M Davis wrote: I think whatever you choose will not please everybody, so just choose something and stick with it. Regarding all the extension naming stuff, I suggest you go with the suffix nomenclature which is more general and applicable to all OSs. I agree with Lars on this one. Everyone knows what an extension is. It's a universal concept even if it's not used as much on non-Windows OSes. There _are_ plenty of programs in *nix which use it internally (likely because it's a lot easier than dealing with mime type) even if they shouldn't. eg: numerous compilers, programming editors,... ;-) The one that really bit me IIRC was Audacious. I had some newly ripped music files which it wouldn't play. As it turns out, the problem was that I had had to redo the settings on my ripping program shortly before, and I had forgotten to put the extension in the file name, so the newly ripped files had no extensions, and Audiacious apparently used the extension to determine whether it could play a particular file. So, of course, it wouldn't play my files, since they had no extensions. Unfortunately, it took me quite a while to figure that out, and I ended up on a bit of a wild goose chase in the interim... This reminds me. I should look into mime types one of these days to see what the appropriate way (if any) would be to put support for them in Phobos. It would be nice to not have to go by extension for the few programs that I have which have to worry about file type. - Jonathan M Davis
Re: Using map instead of iteration
Jonathan M Davis: I'm sure that part of the problem is the fact that a .. b is also used in slicing, where it does not mean the same thing It means the same thing, with a interval literal. - that and iota works just fine, Currently it has a design bug that I've underlined. and increasingly, Andrei and Walter seem to prefer having stuff in the library rather than the language itself when there's no significant gain to be had by putting it in the language. The gain is simplifying the language, removing the special cased syntax of foreach and switch and opSlice, and more, and replacing them with something more general, more polished and generic, that allows more usages and more runtime efficiency. This makes D look less like a pile of special cases and more like a designed language. So you are quite off-mark. See my recent answer: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=131378 Bye, bearophile
where clause
I have discussed this topic already once in past, but I want to talk some more
about it. Lately I am using Haskell a bit, and I'm appreciating this very
simple feature. In D it's not as useful as in Haskell because D allows nested
functions, that are one of its main purposes, but it's a cute thing.
The where allows to write an expression where some parts of it are defined
below it. In the where you are allowed to put one or more variables (immutable
values in Haskell) and functions (values again).
So first of all some usage examples from random Haskell code (Haskell uses
significant indentation, almost as Python):
median xs | even len = (mean . take 2 . drop (mid - 1)) ordered
| otherwise = ordered !! mid
where len = length xs
mid = len `div` 2
ordered = sort xs
pts n =
map (map (intPoint.psPlus (100,0)). ((0,300):). scanl1 psPlus. ((r,300):).
zipWith (\h a - (h*cos a, h*sin a)) rs) hs
where
[r,h,sr,sh] = [50, pi/5, 0.9, 0.75]
rs = take n $ map (r*) $ iterate(*sr) sr
lhs = map (map (((-1)**).fromIntegral)) $ enumBase n 2
rhs = take n $ map (h*) $ iterate(*sh) 1
hs = map (scanl1 (+). zipWith (*)rhs) lhs
levenshtein s1 s2 = last $ foldl transform [0 .. length s1] s2
where transform ns@(n:ns') c = scanl compute (n+1) $ zip3 s1 ns ns'
where compute z (c', x, y) = minimum
[y+1, z+1, x + fromEnum (c' /= c)]
drawTree (width, height) start steps stdgen = do
img - image width height off
setPix img (Pixel start) on
gen - newSTRef stdgen
let -- randomElem :: [a] - ST s a
randomElem l = do
stdgen - readSTRef gen
let (i, stdgen') = randomR (0, length l - 1) stdgen
writeSTRef gen stdgen'
return $ l !! i
-- newPoint :: ST s (Int, Int)
newPoint = do
p - randomElem border
c - getPix img $ Pixel p
if c == off then return p else newPoint
-- wander :: (Int, Int) - ST s ()
wander p = do
next - randomElem $ filter (inRange pointRange) $ adjacent p
c - getPix img $ Pixel next
if c == on then setPix img (Pixel p) on else wander next
replicateM_ steps $ newPoint = wander
stdgen - readSTRef gen
return (img, stdgen)
where pointRange = ((0, 0), (width - 1, height - 1))
adjacent (x, y) = [(x - 1, y - 1), (x, y - 1), (x + 1, y - 1),
(x - 1, y), (x + 1, y),
(x - 1, y + 1), (x, y + 1), (x + 1, y + 1)]
border = liftM2 (,) [0, width - 1] [0 .. height - 1] ++
liftM2 (,) [1 .. width - 2] [0, height - 1]
off = black
on = white
brkdwn = takeWhile (not.null) . unfoldr (Just . second (drop 1) . span ('$'/=))
format j ls = map (unwords. zipWith align colw) rows
where
rows = map brkdwn $ lines ls
colw = map (maximum. map length) . transpose $ rows
align cw w =
case j of
'c' - (replicate l ' ') ++ w ++ (replicate r ' ')
'r' - (replicate dl ' ') ++ w
'l' - w ++ (replicate dl ' ')
where
dl = cw-length w
(l,r) = (dl `div` 2, dl-l)
maze :: Int - Int - StdGen - ST s Maze
maze width height gen = do
visited - mazeArray False
rWalls - mazeArray True
bWalls - mazeArray True
gen - newSTRef gen
liftM2 (,) (rand (0, maxX) gen) (rand (0, maxY) gen) =
visit gen visited rWalls bWalls
liftM2 Maze (freeze rWalls) (freeze bWalls)
where visit gen visited rWalls bWalls here = do
writeArray visited here True
let ns = neighbors here
i - rand (0, length ns - 1) gen
forM_ (ns !! i : take i ns ++ drop (i + 1) ns) $ \there - do
seen - readArray visited there
unless seen $ do
removeWall here there
visit gen visited rWalls bWalls there
where removeWall (x1, y1) (x2, y2) = writeArray
(if x1 == x2 then bWalls else rWalls)
(min x1 x2, min y1 y2)
False
neighbors (x, y) =
(if x == 0then [] else [(x - 1, y)]) ++
(if x == maxX then [] else [(x + 1, y)]) ++
(if y == 0then [] else [(x, y - 1)]) ++
(if y == maxY then [] else [(x, y + 1)])
maxX = width - 1
maxY = height - 1
mazeArray = newArray ((0, 0), (maxX, maxY))
:: Bool - ST s (STArray s (Int, Int) Bool)
printMaze :: Maze - IO ()
printMaze (Maze rWalls bWalls) = do
putStrLn $ '+' : (concat $ replicate (maxX + 1) ---+)
forM_ [0 .. maxY] $ \y - do
putStr |
forM_ [0 .. maxX] $ \x - do
putStr
putStr $ if rWalls ! (x, y) then | else
putStrLn
forM_ [0 .. maxX] $ \x - do
putStr +
putStr $ if bWalls ! (x, y)
Re: Proposal for std.path replacement
However, are you indicating that we should never have more than one module in review at a time? I see some benefit in spreading them out, on the other hand, if we have multiple modules ready for review, it seems like we could be slowing down progress unnecessarily if we ruled that we could only ever have one module under review at a time. We should have only one review at a time. That way each review will be thorough. Boost does that, and I don't want to mess with success - particularly since the Boost community is larger too. Andrei
Re: Using map instead of iteration
On Sunday 06 March 2011 17:20:33 bearophile wrote: Jonathan M Davis: I'm sure that part of the problem is the fact that a .. b is also used in slicing, where it does not mean the same thing It means the same thing, with a interval literal. - that and iota works just fine, Currently it has a design bug that I've underlined. and increasingly, Andrei and Walter seem to prefer having stuff in the library rather than the language itself when there's no significant gain to be had by putting it in the language. The gain is simplifying the language, removing the special cased syntax of foreach and switch and opSlice, and more, and replacing them with something more general, more polished and generic, that allows more usages and more runtime efficiency. This makes D look less like a pile of special cases and more like a designed language. So you are quite off-mark. See my recent answer: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Da rticle_id=131378 If anything, I'd argue to simply remove .. from foreach and have iota be the way to do it. The only other inconsistency is with case statements, but making them have an open right end would likely be problematic (not to mention break tons of code), whereas an open right end is exactly what it should be in the general case. I really don't see the problem other than the fact that using .. in foreach is completely redundant at this point, since we have iota. - Jonathan M Davis
Re: Pretty please: Named arguments
Joel C. Salomon:
Does D have the equivalent of C99's designated initializers?
D2 currently allows code like this (but I don't know if this will be
deprecated, for me sometimes is not easy to remember all things that will be
deprecated):
struct Foo { int x, y, z; }
Foo f1 = { x:1, y:2 };
Foo f2 = { x:1, z:2 };
void main() {}
Bye,
bearophile
Re: Haskell infix syntax
On 3/6/11 6:04 PM, Jonathan M Davis wrote: On Sunday 06 March 2011 09:34:07 Adam D. Ruppe wrote: bearophile: UFCS is a huge hack that I hope to never see in D :-) How is it a hack? I can understand there being implementation problems that can make it undesirable to add, but calling it hack? It's one of the most elegant syntax proposals I've ever seen! It unifies objects and other functions in syntax. It improves encapsulation by giving full support to non-member functions. It improves modularity for the same reason. With ufcs, there'd be no desire to add useless members due to object syntax. Everything is equal - easy extensibility, better protection, cleaner interfaces. It's the opposite of a hack. It is _not_ a hack. Whether it's desirable or not is another matter, but it is _not_ a hack. And really, the term hack is very imprecise and often subjective. It's the sort of accusation that pretty much kills any legitimate debate. It's generally unsupportable and subjective, so it adds nothing to the debate, but it has such a stink about it that it tends to make people avoid whatever was declared to be a hack. I set out to write a post with pretty much the same message. During our long discussions about D2 at the Kahili coffee shop, one of us would occasionally affix that label to one idea or another (often in an attempt to make I don't like it seem stronger). It was very jarring. Andrei
Re: Pretty please: Named arguments
On Sunday 06 March 2011 16:57:17 Joel C. Salomon wrote:
(De-lurking; I've been interested in D for a while, but my programming
is almost exclusively in C -- generally C99.)
Does D have the equivalent of C99's designated initializers?
Were I to attempt something like this in C, the code would go something
like this:
int foo(int height, int width);
struct _foo_args {
int height; int width;
};
#define foo(...) \
foo((struct _foo_args){__VA_ARGS__}.height, \
(struct _foo_args){__VA_ARGS__}.width)
at which point each of these calls:
foo(a, b);
foo(.height = a, .width = b);
foo(.width = b, .height = a);
have the same effect.
I'll readily admit this is *not* pretty, and likely more effort than
it's worth, but is will work.
Are D's compile-time operations not capable of something at *least* this
powerful?
D doesn't have macros. It has incredibly powerful templates as well as string
mixins, but no macros. So, what D has tends to be very powerful, but there are
times when it's more verbose to use than a C macro might be, and there are some
things that you can do with C macros that you can't readily do in D (though
there are a lot of things that yo ucan do with D templates that you could never
do with C macros or even C++ templates - or if you can, it's a _lot_ harder in
C++). It's a lot safer and less error-prone that way though.
In this case, you could do something like this:
int width;
int height;
func(width = 2, height = 7);
That _is_ a bit wasteful though in that it's assigning to local variables which
are likely never used after that. Regardless, I don't think that you can do
something quite like what you're trying to do. If nothing else, I don't think
that D has anything like C99's designated initializers. It has constructors.
- Jonathan M Davis
Re: Problem with parallel map
On Sun, 06 Mar 2011 09:33:05 -0500, dsimcha dsim...@yahoo.com wrote: http://d.puremagic.com/issues/show_bug.cgi?id=5710 It's a DMD issue. I've been meaning to report it for a while. Unfortunately making a workaround for it would be a huge PITA at best and impossible in the toughest use cases. I've run into this problem with regular map as well. I did submit a work-around patch for phobos which copied the delgate instead of sending it through via an alias, which seemed to work.
