> Just out of curiosity, have you planned/thought/considered adding some > C-like lexical preprocessing capabilities to Chapel, ran very early in > compilation?
Apart from the 'include' statement mentioned before, we've discussed some sort of 'ifdef-style' conditional that would be evaluated at parse-time and not influence lexical scopes. The slippery slope there is that, in the limit, one would probably like to use the full param-oriented mechanisms, but in the general case that machinery can't run until function/type resolution time, which is too late for textually-oriented stuff. So the two big questions here are (a) what syntax to use and (b) where to draw the line between what is/is not supported. I've at times desired a way to create shorthand textual aliases for things, which could be considered a poor-man's macro, but would probably be limited to identifier -> expression mappings rather than a more cpp-style identifier/macro -> arbitrary text feature. I'm not fully convinced that this feature is necessary, though, and I think it becomes less so once we have the ability to rename symbols on 'module use' clauses (a planned feature). We haven't really discussed supporting more general macro-like textual expansions. My gut reaction is that I'm not sure we want to get into that business, and that perhaps one should use m4 or cpp prior to compilation if that's what they want. But these last two paragraphs are just my personal opinions and don't reflect any official direction for the language or project. > I tried that quickly but couldn't make it work. Well, not a problem > anymore, since I figured a more clever way to deal with this and could > refactor some large arrays away. However, do you have plans to have > better support for higher-order functions? We'd like to have improved support for higher-order functions, yes, but haven't been able to resource it yet and have had bigger fish to fry in the meantime. > Okay, I might have a look. Would you remind me what exact features > (reindexing, rank change at least?) those changes are going to affect? It removes the need to create slicing, reindexing, and rank change functions for domain maps via the dsiSlice(), dsiReindex(), dsiRankChange() functions. In the branch, you'll see that these routines have been removed for all of our rectangular domain maps other than the DefaultRectangular domain map. > And into another topic: do you know if anyone has wrote any graphic > library or tools using Chapel? Specifically I'd be interested in > functions to plot vector/scalar fields; something similar to what's > found in matlab etc. And output to files would be fine, no need for > application to create windows and all that hassle. I feel like there've been inquiries about this over time and that a few might have taken stabs at it, but I'm not familiar with any significant efforts offhand. It might be worth searching the mailing list archives to see what that turns up. In early language design discussions, we discussed supporting some simple plot() library routines to complement write() and give a Matlab-like ease-of-visualization benefit, but nothing has come of that yet. It's not off the table, just hasn't been cited as a limiting factor in using the language yet (where other things have been). -Brad ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Chapel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-users
