Re: Complete D grammar
Trass3r wrote: Rainer Schuetze Wrote: I've set up a comparison with some notes here: http://www.dsource.org/projects/visuald/wiki/GrammarComparison Very nice comparison style. What would be an appropriate way to discuss grammar changes? I think many things should be simplified/clarified. I'd welcome this. I see a few options, but none is currently perfect: - in a wiki. both dsource and wiki4d don't seem to have discussion pages, though. I'm not sure the comparison tables can be converted to something maintainable - it's currently very verbose html. - here on the newsgroup. this would probably have the widest audience, but also might easily get lost. maybe with keeping track of ideas/results in wiki4d. - in bugzilla. this might get spread into multiple entries causing loss of the overview of the overall grammar. For example, isn't AutoDeclaration already covered by Decl -> StorageClasses Decl and so on? Also there are 3 different instances of mixin: MixinExpression, MixinStatement and MixinDeclaration. Even though they all come down to the same thing. Modifiers like shared are repeated, e.g. in BasicType, Attribute, TypeSpecialization. Also your proposed TypeWithModifier somewhat replicates parts of BasicType (just without the parentheses) I think, the different mixin variants are ok, because you might want to generate different AST for these. But the confusion of const/shared/immutable etc in Attribute,StorageClass,Types,etc causes a lot of headaches.
Re: A case for valueless AA's?
On 2011-03-29 20:11, Andrej Mitrovic wrote: > I had a look at dcollections, it seems to have a few different > implementations of a set. And it has intersection (not sure about > difference or union). It's boost licensed, I wonder if Steve will make > a push of his library to Phobos when its done.. RedBlackTree came from dcollections in the first place. Its internals use pretty much the same backend implementation as dcollecitions' red-black tree does, but the front-end is very different (since dcollections and std.container are very different in philosophy). But as I understand it, he has no intention of getting any of the rest of dcollections in Phobos. His opinions on containers differ from Andrei's, and he said that the other container types are simple enough to reimplement, that there's no need to port them. - Jonathan M Davis
Re: A case for valueless AA's?
I had a look at dcollections, it seems to have a few different implementations of a set. And it has intersection (not sure about difference or union). It's boost licensed, I wonder if Steve will make a push of his library to Phobos when its done..
Re: A case for valueless AA's?
On 3/29/2011 8:37 PM, Jonathan M Davis wrote: We now have std.container.RedBlackTree, which can be used as a set, but it is a tree rather than a hash table. - Jonathan M Davis This isn't a very good set. It doesn't even support basic set primitives like intersection, difference, union, etc. Furthermore, most programs will probably want a hash set. A tree set is only better when you don't have a good hash function or worst case performance is more important than average case. I'm not saying there's anything wrong with RedBlackTree. It's a perfectly good data structure to implement a set on top of. It's just that it's not a "real" set type because it's not meant to be.
[GSoC Proposal draft] High-Level Networking
Google Summer of Code 2011 Proposal Draft Abstract The D programming language standard library (Phobos) lacks modules for high-level networking using application layer protocols. This project aims to provide design and implementation of networking modules for the D programming language. Project details Networking abilities are essential for modern programming languages. Currently Phobos contains modules for low-level networking (std.socket), but lacks modules that provide implementation of application level protocols (FTP, HTTP, SMPT, etc.) The goal of this proposal is to design and implement high-level interface for interaction through application level protocols. I plan to implement TELNET-client, TELNET-server, HTTP-client and FTP-client interfaces. This modules will enable D users to easily build applications interacting with web services, applications controlled via TELNET, etc. I will familiarize myself with existing networking libraries in other programming languages to gather information about commonly used techniques and interfaces that got widely adopted. This information will help me with initial design. To ensure ease of use, I will discuss design of modules with D community, seeking for idiomatic D interfaces. I will be using libcurl as a foundation for implementing this modules. This library is portable, supports a wide range of protocols[1]. Using libcurl will provide a quick start. Benefits for D - Greatly simplify creation of network-enabled applications. About me I'm Max Klyga. I am an undergraduate software engineering student at Belarusian State University of Informatics and Radioelectronics (Minsk, Belarus). I'm mainly interested in system programming and after using C++ for some time I found D and fell in love with it. I also have great interest in data-mining and programming language design. I have good C++, C# and Python skills and experience using Qt-framework. I've been successfully using D in my class projects and enjoyed that experience a lot. Lately I've been developing ODBC wrapper for D in my spare time[2]. References 1. http://en.wikipedia.org/wiki/CURL#libcurl 2. https://bitbucket.org/nekuromento/d-odbc
Re: A case for valueless AA's?
On 2011-03-29 14:34, dsimcha wrote: > == Quote from Andrej Mitrovic (n...@none.none)'s article > > > Here's a little benchmark of Associative Arrays and Dynamic Arrays. I'm > > showing > > traversal and lookup speed. The `static this()` is used to create a random > > collection of words which get stored in the two arrays: > > https://gist.github.com/893340 > > Hash lookups are naturally very fast. So I am inclined to use hashes for > > some of > > my code, but there's a few problems: > > 1. I'm wasting memory. I don't need the values, I only need the keys. But > > I > > can't declare a void[string] hash. > > > 2. AA literals are awkward to write if you don't need the values: > > Aa = ["foo":0, "bar":0, "car":0, > > > > "dar":0, "mar":0, "doo":0]; > > > > So there's redundancy there. > > Anyhow, would this be a good case for valueless AA's? Is that even > > possible? > > They're called sets. In Java I think they're named HashSet and TreeSet. > In Python they're just named Set. Like AAs, the common ways to implement > them are via hashing and balanced binary trees. They are usually fleshed > out with operations like union, intersection and difference. I'm not sure > whether these belong in the core language as an extension of AAs but if > not they definitely belong in std.container. We now have std.container.RedBlackTree, which can be used as a set, but it is a tree rather than a hash table. - Jonathan M Davis
Re: A case for valueless AA's?
On 3/30/11, spir wrote: > On 03/29/2011 11:47 PM, Andrej Mitrovic wrote: >> Looks like not. I've misread Piotr'es post. :) > > There is one in Steven's dcollections. > > Denis Oh yes, I've been meaning to look at dcollections. The last time I saw it I was still confused as to how templates work, but now it's time to have some fun. :)
Re: GCC 4.6
On Wed, 30 Mar 2011 02:04:04 +0300, Andrei Alexandrescu wrote: On 3/29/11 4:37 PM, so wrote: [snip] I find his posts among the most informative. I don't meant to offend anyone here but I think it's worth making a point for your benefit and others'. If you are interested in programming language theory, probably there are better sources of information to use. Though I don't consider myself anywhere near an expert, my masters thesis was on programming language theory, which gives me some amount of perspective. "Cargo culture" would be a gross exaggeration, but much of the knowledge disseminated by bearophile is superficially absorbed literature that is served back semi-digested along with a hodge-podge of personal opinions of various degrees of correctness. The only reason I felt compelled to make this point is the (now obvious) risk in taking such posts as a good source of information. It is is dangerous to take non-critically the occasional enormity that sneaks in. That's why I suggested in the past and am suggesting it again - please don't feign expertise as some may actually fall for it. I have no doubt great personal improvement has been made in the past years, but the tone is still an octave above what it could be at its best. Thanks, Andrei Probably i misused the word informative, what i meant was he occasionally brings up topics that i wasn't aware of and quite possibly i wouldn't even if i try to browse some PL related sites. They tend to be biased on certain languages and paradigms which leads to an hostility towards some ideas. I would be the last one on earth that would buy something because of a commercial, it is just a starting point.
Re: GSoC-2011 project:: Containers
On 2011-03-29 14:50, dsimcha wrote: > == Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article > > > The fancier stuff would be nice, but we don't even have a doubly-linked > > list yet. We should get the simpler stuff sorted out before we get > > particularly fancy, not to mention that it's usually the simple stuff > > that gets heavily used. > > For the most part I agree, but a doubly linked list might be **too** > simple. Linked lists are so trivial to implement that I'd tend to roll my > own that does exactly what I need with regard additional behavior on > insertion, etc. rather than wrapping a library solution to get these > features. A doubly-linked list is on the list of containers that every standard library should have or it's likely to be considered lacking. I can understand rolling your own for specific uses, but _I_ sure don't want to be doing that if I don't have to. If I want a doubly-linked list, I want to be able to just create a standard one and use it. C++, C#, and Java all have doubly-linked lists in their standard libraries. If no one else ever implements a doubly-linked list for Phobos, I'll probably do it eventually simply because it's one of the containers that is on the short list of containers that pretty much every standard library has. - Jonathan M Davis
Re: A case for valueless AA's?
On 03/29/2011 11:47 PM, Andrej Mitrovic wrote: Looks like not. I've misread Piotr'es post. :) There is one in Steven's dcollections. Denis -- _ vita es estrany spir.wikidot.com
Re: A case for valueless AA's?
On 03/29/2011 11:43 PM, Andrej Mitrovic wrote:
A use case for this could be a file system search:
void[string] names; // unique names to find
string[] results;
foreach (string name; dirEntries(curdir, SpanMode.deep))
{
if (name.basename in names)
results ~= name;
}
With string arrays the `if` check might slow things down.
There are tons of use cases for sets. Unfortunately, implementation (either as
hashed collections or binary trees) is far more complicated than for sequential
collections (array, list). Especially, it highly depends on the element type.
Thus, sets are rarely a builtin type.
For this reason, probably, people often wrongly use arrays/lists where sets are
appropriate. This means, mainly, where the primary operation is a test of
membership/containment. (Also set operations like set equality, union,
intersection...)
The pseudo-value trick you used stil a good one: people often build sets from
AAs with a value of true for each key/element (thus, set[x] returns true if x
is present in set -- but this works only in implementations where absence of x
does not throw).
Denis
--
_
vita es estrany
spir.wikidot.com
Re: Review of std.net.isemail part 2
Jacob Carlborg Wrote: > I've made a few minor changes: > > * Renamed EmailStatusCode.Off -> None and On -> Any > * Added and clarified the documentation for EmailStatusCode.Any and None > * Updated the documentation > > Github: https://github.com/jacob-carlborg/phobos/tree/isemail > Docs: http://dl.dropbox.com/u/18386187/isemail.html > > -- > /Jacob Carlborg I believe enum values are to be named lowercase first. EmailStatusCode.any
Re: A case for valueless AA's?
"Andrej Mitrovic" wrote in message news:imtirq$292g$1...@digitalmars.com... > Here's a little benchmark of Associative Arrays and Dynamic Arrays. I'm > showing traversal and lookup speed. The `static this()` is used to create > a random collection of words which get stored in the two arrays: > > https://gist.github.com/893340 > > Hash lookups are naturally very fast. So I am inclined to use hashes for > some of my code, but there's a few problems: > > 1. I'm wasting memory. I don't need the values, I only need the keys. But > I can't declare a void[string] hash. > > 2. AA literals are awkward to write if you don't need the values: > Aa = ["foo":0, "bar":0, "car":0, > "dar":0, "mar":0, "doo":0]; > > So there's redundancy there. > > Anyhow, would this be a good case for valueless AA's? Is that even > possible? > > I could just wrap an AA in a custom type that has a nice constructor, > which takes care of issue #2. But I don't know how to get rid of the > values, which leaves the issue #1. I frequently find use for such a thing. I've always used "bool[whatever]" for that purpose. Piotr's suggestion of "void[0][whatever]" never occurred to me, I may try that sometime.
Re: GCC 4.6
On 3/29/11 4:37 PM, so wrote: [snip] I find his posts among the most informative. I don't meant to offend anyone here but I think it's worth making a point for your benefit and others'. If you are interested in programming language theory, probably there are better sources of information to use. Though I don't consider myself anywhere near an expert, my masters thesis was on programming language theory, which gives me some amount of perspective. "Cargo culture" would be a gross exaggeration, but much of the knowledge disseminated by bearophile is superficially absorbed literature that is served back semi-digested along with a hodge-podge of personal opinions of various degrees of correctness. The only reason I felt compelled to make this point is the (now obvious) risk in taking such posts as a good source of information. It is is dangerous to take non-critically the occasional enormity that sneaks in. That's why I suggested in the past and am suggesting it again - please don't feign expertise as some may actually fall for it. I have no doubt great personal improvement has been made in the past years, but the tone is still an octave above what it could be at its best. Thanks, Andrei
Re: [GSoC Proposal] Statically Checked Measurement Units
On 3/30/11 12:20 AM, Cristi Cobzarenco wrote: Well they don't _have_ to be the same type as long they're convertible to one another, and one can make sure they're convertible based on the result of the double-inclusion. But how would you make them _implicitly_ convertible then? David
Re: A case for valueless AA's?
Piotr Szturmaj:
> void[0][string] aa;
> aa["key"] = [];
> assert("key" in aa);
Nice. I have done a benchmark, and it seems a void[0][int] uses the same amount
of memory as a int[int]. I have not tried a void[0][string].
Bye,
bearophile
Re: [GSoC Proposal] Statically Checked Measurement Units
On 3/29/11 2:17 PM, spir wrote: On 03/29/2011 04:45 PM, Andrei Alexandrescu wrote: Waow, this is a great explanation of expected benefits of units, I guess. Also, isn't this precisely the power of true typedefs? Typedefs would not allow defining categorical types (e.g. no arithmetic). Fortunately there are already means in the language for defining such types. Andrei
Re: [GSoC Proposal] Statically Checked Measurement Units
Well they don't _have_ to be the same type as long they're convertible to
one another, and one can make sure they're convertible based on the result
of the double-inclusion. It does make more sense for them to be the same
type, I agree, therefore I'll be sticking to the .mangleof version. Dummy
objects are fine, the only problem is the fact that one has to define the
extra objects (and, when one wants to count objects, you'll need to define a
different type). I was also considering shorthand symbols, since it seems
like a natural addition, I'll have think a bit more on how exactly to do
that, to avoid collisions.
Regarding if this is appropriate for GSoC. It doesn't take me 12 weeks to
write a prototype, sure. But to have a library fit to be part of the
standard library of language takes a lot of laborious testing, going through
use-cases and making sure it is highly usable. Also, there should be an
effort to make sure other libraries make use of units when appropriate (like
Andrei suggested std.datetime) etc. As we all know it takes 90% of the time
to code 10% of the code. I think all of this extra polish, reliability and
usability is very important and takes the extra 11 weeks. It's not the most
glorified kind of work, but I really think it's worth it.
On 29 March 2011 23:40, David Nadlinger wrote:
> On 3/29/11 3:49 PM, Cristi Cobzarenco wrote:
>
>> To David:
>> Ok, right now, I got two working versions, one sorting by .mangleof and
>> one performing a double-inclusion test on the tuples. Both work, I can't
>> see any performance increase in the .mangleof one, but if .mangleof
>> returns unique string, I say we use it this way.
>>
>
> To be honest, I still don't see how you are able to get away without
> canonicalization in the first place; would you mind to elaborate on how you
> solve the issue of different ordering of expression yielding types? This is
> not about the algorithm to determine whether two types are semantically
> equivalent, where your algorithm would work fine as well, but about the
> actual D types. If you don't sort them, Quantity!(BaseUnitExp!(Meter, 1),
> BaseUnitExp!(Second, -2)) and Quantity!(BaseUnitExp!(Second, -2),
> BaseUnitExp!(Meter, 1)) would be different types, which is not desirable for
> obvious reasons.
>
>
> Regarding my string little DSL. I have 3 solutions right now:
>> 1. Drop the DSL altogether, right now my system would work perfectly
>> fine with boost-like tuples (a list of units alternating with exponents):
>> Quantity!(Metre,1,Second,-1) speed = distance/time;
>> While less readable, this doesn't have the disadvantages of the following
>> 2.
>>
>> 2. Use a mixin template to declare the expression parser in the current
>> scope:
>> mixin DeclareExprQuantity!();
>>
>> struct Metre {}
>> struct Second {}
>> struct Kg {}
>>
>> void f() {
>>ExprQuantity!("Metre/Second * Kg^-1") q = speed / mass;
>> }
>> This works, is readable, but it uses C-preprocessor like behaviour
>> (read: black vodoo) - a library declaring something in your scope isn't
>> very nice.
>>
>> […]
>>
>>
>> The only completely clean alternative would be the abominable:
>> Quantity!( mixin(Expr!("Metre/Second")) ) q;
>>
>
> Get out of my head! Immediately! ;) Just kidding – incidentally I
> considered exactly the same options when designing my current prototype. My
> current approach would be a mix between 1 and 2: I don't think the Boost
> approach of using »dummy« instances of units is any less readable than your
> proposed one when you don't deal with a lot of units. For example, consider
>
> enum widgetCount = quantity!("Widget")(2);
> vs.
> enum widgetCount = 2 * widgets;
>
> This could also be extended to type definitions to avoid having to manually
> write the template instantiation:
>
> Quantity!("meter / second", float) speed;
> vs.
> typeof(1.f * meter / second) speed;
>
> There are situations, though, where using unit strings could considerable
> improve readability, namely when using lots of units with exponents. In
> these cases, a mixin could be used to bring all the types in scope for the
> »parsing template«, similar to the one you suggested. If a user of the
> library things could use an additional mixin identifier to clarify the
> code, e.g. »mixin UnitStringParser U; […] U.unit!"m/s"«).
>
> But a more attractive solution would exploit the fact that you would mostly
> use units with a lot of exponents when working with a »closed« unit system
> without the need for ad-hoc extensions, like the SI system, which would
> allow you to use unit symbols instead of the full name, which wouldn't need
> to be globally unique and wouldn't pollute the namespace (directly defining
> a type »m« to express meters would probably render the module unusable
> without static imports).
>
> It would essentially work by instantiating a parser template with all the
> named units. Thus, the parser would know all the types and could query them
> for additional properties like short names/symbo
Re: std.signals
On 3/30/11 12:00 AM, teo wrote: I did some refactoring of the std.signals module and would like to hear your comments on it. Where is the appropriate place for posting the source code? You might want to fork the Phobos project on GitHub, put your changes to std.signal changes into a branch, and then start a discussion on it here on this NG with a link to your branch at GitHub. David
Re: expression templates
On Tue, 29 Mar 2011 22:56:10 +0300, dsimcha wrote:
Occasionally i encounter this argument that operator overloading is bad
thing when it is abused.
I don't overload operators offensively myself, i use dot(vec, vec)
cross(vec, vec) for example because there is not a suitable operator and
these names suits much better.
On the other hand i am not against languages being flexible, quite
contrary i don't call it a language if it is not.
OO is an impressive tool and we need tools like this for better libraries.
You can't change a language for a long time but you can update a library
in very short period of time.
vec add(a, b) { return a.x - b.x }
vec operator+(a, b) { return a.x - b.x }
Is there a difference?
std.signals
I did some refactoring of the std.signals module and would like to hear your comments on it. Where is the appropriate place for posting the source code?
Re: Complete D grammar
Trass3r wrote: Rainer Schuetze wrote: I've extracted the website grammar using some combination of scripts from the ddoc sources, so if there is interest, I can dig them up... Yep, please make them publicly available so they don't get lost. Though I think we should have an extra official page with the complete grammar in addition to the widespread snippets anyway. I've uploaded the script and the grammar used for the comparison (a few month old) and the grammar from the current doc sources to http://www.dsource.org/projects/visuald/browser/grammar See the header of gen_grammar.sh for a very short description what to do to run the generation.
Re: constexpr and CTFE
On Sun, 27 Mar 2011 17:50:00 +0300, bearophile wrote: This first question is mostly for D.learn, but below I show a partially related link too, so I put both of them here. If you have library code, and the users of your library run one of your functions at compile time, later if you change your function it may not run at compile time any more. So isn't the quality of being able to run at compile time part of the signature of the function? --- GCC 4.6 implements the C++0x constexpr. I've found a note about constexpr, that touches the topic of logic const too, purity, memoization: http://stackoverflow.com/questions/4748083/when-should-you-use-constexpr-capability-in-c0x/4750253#4750253 Bye, bearophile constexpr is a primitive utility comparing to D, and why it is designed the way it is in C++ is IMO nothing but to maintain backwards compatibility, not because it has anything over what we have here. enum ctfe = fun(); If "fun" no longer ctfe'able compiler will output and error and that is all we need. Why would a library designer care if his code will be executed at compile or runtime? No reason i can think of.
Re: Complete D grammar
Walter Bright wrote: On 3/28/2011 11:46 PM, Rainer Schuetze wrote: I've set up a comparison with some notes here: http://www.dsource.org/projects/visuald/wiki/GrammarComparison I thought I fixed the grammar issues listed in Bugzilla. The comparison is from the time I wrote the parser, so it is a few month old. Checking the latest docs, there are already quite a number of issues fixed, but also some new have crept in. I'll redo the comparison with the latest extracted grammar... Could you please add a bugzilla entry for your wiki notes? I hope you mean an entry with a link to the wiki. The comparison itself might a bit too large itself for bugzilla (html is larger than 800kB) ;-)
Re: GSoC-2011 project:: Containers
== Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article > The fancier stuff would be nice, but we don't even have a doubly-linked list > yet. We should get the simpler stuff sorted out before we get particularly > fancy, not to mention that it's usually the simple stuff that gets heavily > used. For the most part I agree, but a doubly linked list might be **too** simple. Linked lists are so trivial to implement that I'd tend to roll my own that does exactly what I need with regard additional behavior on insertion, etc. rather than wrapping a library solution to get these features.
Re: A case for valueless AA's?
Looks like not. I've misread Piotr'es post. :)
Re: [GSoC Proposal] Statically Checked Measurement Units
On 3/29/11 3:49 PM, Cristi Cobzarenco wrote:
To David:
Ok, right now, I got two working versions, one sorting by .mangleof and
one performing a double-inclusion test on the tuples. Both work, I can't
see any performance increase in the .mangleof one, but if .mangleof
returns unique string, I say we use it this way.
To be honest, I still don't see how you are able to get away without
canonicalization in the first place; would you mind to elaborate on how
you solve the issue of different ordering of expression yielding types?
This is not about the algorithm to determine whether two types are
semantically equivalent, where your algorithm would work fine as well,
but about the actual D types. If you don't sort them,
Quantity!(BaseUnitExp!(Meter, 1), BaseUnitExp!(Second, -2)) and
Quantity!(BaseUnitExp!(Second, -2), BaseUnitExp!(Meter, 1)) would be
different types, which is not desirable for obvious reasons.
Regarding my string little DSL. I have 3 solutions right now:
1. Drop the DSL altogether, right now my system would work perfectly
fine with boost-like tuples (a list of units alternating with exponents):
Quantity!(Metre,1,Second,-1) speed = distance/time;
While less readable, this doesn't have the disadvantages of the following 2.
2. Use a mixin template to declare the expression parser in the current
scope:
mixin DeclareExprQuantity!();
struct Metre {}
struct Second {}
struct Kg {}
void f() {
ExprQuantity!("Metre/Second * Kg^-1") q = speed / mass;
}
This works, is readable, but it uses C-preprocessor like behaviour
(read: black vodoo) - a library declaring something in your scope isn't
very nice.
[…]
The only completely clean alternative would be the abominable:
Quantity!( mixin(Expr!("Metre/Second")) ) q;
Get out of my head! Immediately! ;) Just kidding – incidentally I
considered exactly the same options when designing my current prototype.
My current approach would be a mix between 1 and 2: I don't think the
Boost approach of using »dummy« instances of units is any less readable
than your proposed one when you don't deal with a lot of units. For
example, consider
enum widgetCount = quantity!("Widget")(2);
vs.
enum widgetCount = 2 * widgets;
This could also be extended to type definitions to avoid having to
manually write the template instantiation:
Quantity!("meter / second", float) speed;
vs.
typeof(1.f * meter / second) speed;
There are situations, though, where using unit strings could
considerable improve readability, namely when using lots of units with
exponents. In these cases, a mixin could be used to bring all the types
in scope for the »parsing template«, similar to the one you suggested.
If a user of the library things could use an additional mixin
identifier to clarify the code, e.g. »mixin UnitStringParser U; […]
U.unit!"m/s"«).
But a more attractive solution would exploit the fact that you would
mostly use units with a lot of exponents when working with a »closed«
unit system without the need for ad-hoc extensions, like the SI system,
which would allow you to use unit symbols instead of the full name,
which wouldn't need to be globally unique and wouldn't pollute the
namespace (directly defining a type »m« to express meters would probably
render the module unusable without static imports).
It would essentially work by instantiating a parser template with all
the named units. Thus, the parser would know all the types and could
query them for additional properties like short names/symbols, etc. In code:
---
module units.si;
[…]
alias UnitSystem!(Meter, Second, …) Si;
---
module client;
import units.si;
auto inductance = 5.0 * Si.u!"m^2 kg/(s^2 A^2)";
---
This could also be combined with the mixin parser approach like this:
---
import units.si;
mixin UnitStringParser!(Si) U;
---
But to reiterate my point, I don't think a way to parse unit strings is
terribly important, at least not if it isn't coupled with other things
like the ability to add shorthand symbols.
David
Re: A case for valueless AA's?
Oh there's a container? I'll take a look, thanks guys.
Re: A case for valueless AA's?
A use case for this could be a file system search:
void[string] names; // unique names to find
string[] results;
foreach (string name; dirEntries(curdir, SpanMode.deep))
{
if (name.basename in names)
results ~= name;
}
With string arrays the `if` check might slow things down.
Re: GCC 4.6
Listen kid, you're some biology student, right? You're just coding for fun. And more importantly, you haven't participated in any long term real world systems programming projects. This kind of work experience doesn't give you the competence to evaluate the knowledge and work of people with tens of years of programming experience under their belt. You might be terribly smart, but you're missing the point. Can you see what we are building here? A whole language ecosystem. Andrei has done great work by attracting competent CS persons in to the community. The development is changing. We need to find important persons, organizations, solve project management issues and all kinds of non-technical stuff now. Some kid posting yet another daily feature proposal isn't helping us at all. It's distracting and just plain noise. Can you see this from our POV? I really hope this forum is getting moderation once the community grows large enough. I find his posts among the most informative. As you also pointed out, he is doing a lot. Still, if one doesn't like it he can always ignore. On another note: I just hope this language never gets matured in the sense you are suggesting and the community improves it in every opportunity. To make this even more possible we need language features that ease (or make possible) the development of library solutions.
Re: A case for valueless AA's?
Andrej Mitrovic wrote:
1. I'm wasting memory. I don't need the values, I only need the keys. But I
can't declare a void[string] hash.
But I don't know how to get rid of the values, which leaves the issue #1.
Maybe static array of zero length? From documentation:
"A static array with a dimension of 0 is allowed, but no space is
allocated for it. It's useful as the last member of a variable length
struct, or as the degenerate case of a template expansion."
And this code works:
void[0][string] aa;
aa["key"] = [];
assert("key" in aa);
But anyway, I feel that dedicated HashSet container would be more
appropriate.
Re: GSoC-2011 project:: Containers
Fawzi Mohamed: > Also variations of those presented in Purely Functional Data > Structures of Chris Okasaki, would be nice to have. A finger tree seems useful. Bye, bearophile
Re: GSoC-2011 project:: Containers
On 2011-03-29 12:32, spir wrote: > On 03/29/2011 08:34 PM, Ishan Thilina wrote: > >> I can try to answer your questions, but I have not applied to be an > >> official mentor. Just want to make that clear. > >> > >> My previous message was "I would be a mentor for this, but (reasons why > >> I will not)" > >> > >> Sorry if that is not what you read. > >> > >> -Steve > > > > That's ok, You have given me enough encouragement to carry on this > > project. :-) > > > > - > > > > The project idea page gives only a brief introduction to the project. > > From the ongoing conversation in this mailing list I feel that different > > people different expectations from this project. But it is hard to make > > everyone happy. (Me my self being new to will need more time to get > > familiar with the advanced concepts of D.) So I want to know what are > > the containers that you hope me to implement in phobos? > > I have in mind a general Tree & Node, or TreeNode idea; especially > implementing all common tree traversal schemes (including leaves only) and > the background mechanisms to insert/remove/change given nodes and > search/count/replace given values. It may not be used as is --because > various tree kinds actually are very different-- but could be highly > useful, I guess, either as template or as supertype to be derived from. > Comments? (I would probably do it anyway.) I'm not sure that what you're describing would really be appropriate for std.container. It sounds like what you want isn't really a container but rather the building blocks for a container. What really need at this point is more of the basic container types that your average standard library has. We only really have a vector/ArrayList type (Array), a singly-linked list (SList), and a red-black tree (RedBlackTree). I think that the only thing that we really have in std.container beyond those is BinaryHeap which seems to be more of a container wrapper than a proper container. The fancier stuff would be nice, but we don't even have a doubly-linked list yet. We should get the simpler stuff sorted out before we get particularly fancy, not to mention that it's usually the simple stuff that gets heavily used. - Jonathan M Davis
Re: A case for valueless AA's?
== Quote from Andrej Mitrovic (n...@none.none)'s article > Here's a little benchmark of Associative Arrays and Dynamic Arrays. I'm > showing traversal and lookup speed. The `static this()` is used to create a random collection of words which get stored in the two arrays: > https://gist.github.com/893340 > Hash lookups are naturally very fast. So I am inclined to use hashes for some > of my code, but there's a few problems: > 1. I'm wasting memory. I don't need the values, I only need the keys. But I can't declare a void[string] hash. > 2. AA literals are awkward to write if you don't need the values: > Aa = ["foo":0, "bar":0, "car":0, > "dar":0, "mar":0, "doo":0]; > So there's redundancy there. > Anyhow, would this be a good case for valueless AA's? Is that even possible? They're called sets. In Java I think they're named HashSet and TreeSet. In Python they're just named Set. Like AAs, the common ways to implement them are via hashing and balanced binary trees. They are usually fleshed out with operations like union, intersection and difference. I'm not sure whether these belong in the core language as an extension of AAs but if not they definitely belong in std.container.
A case for valueless AA's?
Here's a little benchmark of Associative Arrays and Dynamic Arrays. I'm showing traversal and lookup speed. The `static this()` is used to create a random collection of words which get stored in the two arrays: https://gist.github.com/893340 Hash lookups are naturally very fast. So I am inclined to use hashes for some of my code, but there's a few problems: 1. I'm wasting memory. I don't need the values, I only need the keys. But I can't declare a void[string] hash. 2. AA literals are awkward to write if you don't need the values: Aa = ["foo":0, "bar":0, "car":0, "dar":0, "mar":0, "doo":0]; So there's redundancy there. Anyhow, would this be a good case for valueless AA's? Is that even possible? I could just wrap an AA in a custom type that has a nice constructor, which takes care of issue #2. But I don't know how to get rid of the values, which leaves the issue #1.
Review of std.net.isemail part 2
I've made a few minor changes: * Renamed EmailStatusCode.Off -> None and On -> Any * Added and clarified the documentation for EmailStatusCode.Any and None * Updated the documentation Github: https://github.com/jacob-carlborg/phobos/tree/isemail Docs: http://dl.dropbox.com/u/18386187/isemail.html -- /Jacob Carlborg
Re: GSoC-2011 project:: Containers
On 29-mar-11, at 21:32, spir wrote: On 03/29/2011 08:34 PM, Ishan Thilina wrote: I can try to answer your questions, but I have not applied to be an official mentor. Just want to make that clear. My previous message was "I would be a mentor for this, but (reasons why I will not)" Sorry if that is not what you read. -Steve That's ok, You have given me enough encouragement to carry on this project. :-) - The project idea page gives only a brief introduction to the project. From the ongoing conversation in this mailing list I feel that different people different expectations from this project. But it is hard to make everyone happy. (Me my self being new to will need more time to get familiar with the advanced concepts of D.) So I want to know what are the containers that you hope me to implement in phobos? I have in mind a general Tree & Node, or TreeNode idea; especially implementing all common tree traversal schemes (including leaves only) and the background mechanisms to insert/remove/change given nodes and search/count/replace given values. It may not be used as is --because various tree kinds actually are very different-- but could be highly useful, I guess, either as template or as supertype to be derived from. Comments? (I would probably do it anyway.) I would very much like to have also persistent containers. I have implemented a Batched array for example in D1, which can grow on one side, and one can have persistent slices, and pointers to elements that remain fixed. For structures that just grow and multithreaded programming without (or with very limited) locking these structures are very useful. Also variations of those presented in Purely Functional Data Structures of Chris Okasaki, would be nice to have. Fawzi
Re: expression templates
dsimcha: > Reasonable people can disagree on this, but I say definitely yes. I think the Python set API was designed by the great Raymond Hettinger, one of the best Python developers regarding data structures, algorithms, etc, and a person able to write the most elegant and clean C code, I respect his skills about as much as Don skills. In years of usage I have had no problems with that API, and from the main Python newsgroup in some years I have not read people complain about that API. For not simple set operations in Python I often use English methods instead of some operators because I prefer my code to be more readable and because in my code the second operand often is not a set, so I can't use operators. In the end I am able to survive even without operator overloading :-) In Bugzilla so far I have never added an enhancement request regarding opCmp. Bye, bearophile
Re: expression templates
== Quote from KennyTM~ (kenn...@gmail.com)'s article > On Mar 30, 11 03:15, dsimcha wrote: > > == Quote from bearophile (bearophileh...@lycos.com)'s article > >> The operator overloading done with opCmp is too much coarse even if you > >> want to > > implement sets with operators like<=< > >= == for subset, etc. > > > > Can you please give an example of where<=,>, etc. are useful for > > representing > > set operations? My naive opinion (i.e. without understanding your use > > case) is > > that using comparison operators to represent anything besides partial or > > total > > ordering is a severe abuse of operator overloading. (Their use to represent > > ordering of corresponding elements of a vector or matrix is a borderline > > case.) > If 'a <= b' means 'a' is a subset of 'b', then (Set, <=) does form a > partial order. > That said, the current opCmp design is capable of comparing sets and any > partial orders if the return type can be relaxed to 'float': > if (a == b) return 0; > else if (a is subset of b) return -1; > else if (b is subset of a) return 1; > else /* unordered */ return NaN; Technically you're right, but I question whether thinking of this as an ordering is ever useful in practice.
Re: expression templates
On Mar 30, 11 03:15, dsimcha wrote: == Quote from bearophile (bearophileh...@lycos.com)'s article The operator overloading done with opCmp is too much coarse even if you want to implement sets with operators like<=< > >= == for subset, etc. Can you please give an example of where<=,>, etc. are useful for representing set operations? My naive opinion (i.e. without understanding your use case) is that using comparison operators to represent anything besides partial or total ordering is a severe abuse of operator overloading. (Their use to represent ordering of corresponding elements of a vector or matrix is a borderline case.) If 'a <= b' means 'a' is a subset of 'b', then (Set, <=) does form a partial order. That said, the current opCmp design is capable of comparing sets and any partial orders if the return type can be relaxed to 'float': if (a == b) return 0; else if (a is subset of b) return -1; else if (b is subset of a) return 1; else /* unordered */ return NaN;
Re: expression templates
Oh my, the C++ streams syntax. I hated that thing.
Re: Is D more complex than C++?
"spir" wrote in message news:mailman.2896.1301428213.4748.digitalmar...@puremagic.com... > On 03/29/2011 09:17 PM, Steven Schveighoffer wrote: >> On Tue, 29 Mar 2011 15:09:38 -0400, Don wrote: >> >>> Andrej Mitrovic wrote: This is obviously the same old D troll. Stop feeding him guys. >>> >>> This one was a good question. Actually a very good one. Regardless of >>> the >>> motivation behind it. >> >> Every once in a while, a troll outwits himself into generating a useful >> discussion, and see how sour he gets when he realizes his words aren't >> provoking the right emotions :) > > Maybe this is one possible right reaction to trolling (in some cases): > take their words seriously, if not literally. > Yea, at the very least, I think it helps separate the true trolls from legitimate people who might just not be very good at diplomacy.
Re: expression templates
== Quote from bearophile (bearophileh...@lycos.com)'s article > This is not terrible, because for those two operations I define only the > method with English name, but this is a small limit of opCmp. In expression templates you are able to use the same solution. > Is this usage for the set API operator overloading abuse? I am not sure. I > think it's acceptablre. Reasonable people can disagree on this, but I say definitely yes. I don't regret that operator overloading exists in D since I don't believe in throwing the baby out with the bath water when it comes to language design. That said, I believe that unless an operator overload does something conceptually identical to what it does for builtin types, it's an abuse of operator overloading. For example, using '+' for string concatenation, '<<' to write to streams, '+' to append to a stack, or comparison operators for dealing with sets is a severe abuse. I'm even hesitant to use '*' for matrix multiplication since I fail to see how matrix multiplication is conceptually related to scalar multiplication. I wish these were treated as unrelated operations in standard mathematical notation, for example using '.' for matrix multiplication. However, if I ever get around to finishing my SciD enhancements, I will grudgingly defer to de facto standards and use it.
Re: Is D more complex than C++?
On 03/29/2011 09:17 PM, Steven Schveighoffer wrote: On Tue, 29 Mar 2011 15:09:38 -0400, Don wrote: Andrej Mitrovic wrote: This is obviously the same old D troll. Stop feeding him guys. This one was a good question. Actually a very good one. Regardless of the motivation behind it. Every once in a while, a troll outwits himself into generating a useful discussion, and see how sour he gets when he realizes his words aren't provoking the right emotions :) Maybe this is one possible right reaction to trolling (in some cases): take their words seriously, if not literally. denis -- _ vita es estrany spir.wikidot.com
Re: expression templates
On 03/29/2011 09:15 PM, dsimcha wrote: == Quote from bearophile (bearophileh...@lycos.com)'s article The operator overloading done with opCmp is too much coarse even if you want to implement sets with operators like<=< > >= == for subset, etc. Can you please give an example of where<=,>, etc. are useful for representing set operations? My naive opinion (i.e. without understanding your use case) is that using comparison operators to represent anything besides partial or total ordering is a severe abuse of operator overloading. (Their use to represent ordering of corresponding elements of a vector or matrix is a borderline case.) Agreed. Wild guess: maybe Bearophile meant < <= > >= as operators for subset/superset predicates? Anyway, this is a very different idea. A different, far less abusing, use of those operators on sets may be to compare cardinality, as in the original theory of natural numbers as sets; here, I guess, the analogy is far more meaningful and totally consistent. Denis -- _ vita es estrany spir.wikidot.com
Re: expression templates
dsimcha: >Can you please give an example of where <=, >, etc. are useful for >representing set operations? My naive opinion (i.e. without understanding >your use case) is that using comparison operators to represent anything >besides partial or total ordering is a severe abuse of operator overloading.< recent Python versions have a built-in set type, I use them very often, so in the dlibs1 I have implemented a set struct with the same API, you see it spread here: http://docs.python.org/library/stdtypes.html#set Most set operations are doable both with an operator and a with method with an English name (the main difference is that the methods accept a generic iterable too beside a set, while operators require both operators to be set). If you try to implement the issubset/isSubset, opCmp is not enough, because as you say a full opCmp can't be defined on sets, in D we can't overload <= >= among sets. This is not terrible, because for those two operations I define only the method with English name, but this is a small limit of opCmp. In expression templates you are able to use the same solution. Is this usage for the set API operator overloading abuse? I am not sure. I think it's acceptablre. Bye, bearophile
Re: GSoC-2011 project:: Containers
On 03/29/2011 08:34 PM, Ishan Thilina wrote: I can try to answer your questions, but I have not applied to be an official mentor. Just want to make that clear. My previous message was "I would be a mentor for this, but (reasons why I will not)" Sorry if that is not what you read. -Steve That's ok, You have given me enough encouragement to carry on this project. :-) - The project idea page gives only a brief introduction to the project. From the ongoing conversation in this mailing list I feel that different people different expectations from this project. But it is hard to make everyone happy. (Me my self being new to will need more time to get familiar with the advanced concepts of D.) So I want to know what are the containers that you hope me to implement in phobos? I have in mind a general Tree & Node, or TreeNode idea; especially implementing all common tree traversal schemes (including leaves only) and the background mechanisms to insert/remove/change given nodes and search/count/replace given values. It may not be used as is --because various tree kinds actually are very different-- but could be highly useful, I guess, either as template or as supertype to be derived from. Comments? (I would probably do it anyway.) Denis -- _ vita es estrany spir.wikidot.com
Re: Bruno Medeiros has been accepted as a GSoC 2011 mentor for Digital Mars
On 03/29/2011 03:21 PM, Bruno Medeiros wrote: On 29/03/2011 13:46, Steven Schveighoffer wrote: On Tue, 29 Mar 2011 08:04:00 -0400, Bruno Medeiros wrote: On 27/03/2011 19:57, Andrei Alexandrescu wrote: Bruno Medeiros from Google has been accepted as a mentor for the Google Summer of Code 2011 program for Digital Mars. Please join me in congratulating and wishing the best to Bruno. We have three mentors and two pending applications. We are always looking for mentor and student applications. Please refer to this page for how to apply: http://d-programming-language.org/gsoc2011.html Andrei Thanks. I hope to do a good job if indeed any IDE related proposals get accepted. BTW, that page lists me are working for Google, but that is incorrect, not sure what gave you that idea (I wish it were true though :P ) I had that impression too. There was a post you made a while back where I thought you suggested quite subtly that you work for them. But I can't find it now (unfortunately my browser doesn't support the "find all messages which made me think Bruno Medeiros works for google" search feature). -Steve Hum, I did apply to Google on August last year (went as far as the onsite interview), and tweeted about it, but also that I wasn't accepted. :P But here on the NG I'm not sure what might have given that impression. I'm a bit of Google fan, but then again, who isn't? *cheeky* Me. Rather, I'm afraid by Google. Denis -- _ vita es estrany spir.wikidot.com
Re: Is D more complex than C++?
On Tue, 29 Mar 2011 15:09:38 -0400, Don wrote: Andrej Mitrovic wrote: This is obviously the same old D troll. Stop feeding him guys. This one was a good question. Actually a very good one. Regardless of the motivation behind it. Every once in a while, a troll outwits himself into generating a useful discussion, and see how sour he gets when he realizes his words aren't provoking the right emotions :) -Steve
Re: [GSoC Proposal] Statically Checked Measurement Units
On 03/29/2011 04:45 PM, Andrei Alexandrescu wrote:
On 03/29/2011 02:06 AM, Don wrote:
Cristi Cobzarenco wrote:
First, let me apologize for this very late entry, it's the end of
university and it's been a very busy period, I hope you will still
consider it.
Note this email is best read using a fixed font.
PS: I'm really sorry if this is the wrong mailing list to post and I
hope you'll forgive me if that's the case.
=== Google Summer of Code Proposal: Statically Checked Units ===
Abstract
-
Measurement units allow to statically check the correctness of
assignments and expressions at virtually no performance cost and very
little extra effort. When it comes to physics the advantages are
obvious – if you try to assign a force a variable measuring distance,
you've most certainly got a formula wrong somewhere along the way.
Also, showing a sensor measurement in gallons on a litre display that
keeps track of the remaining fuel of a plane (a big no-no) is easily
avoidable with this technique. What this translates is that one more
of the many hidden assumptions in source code is made visible: units
naturally complement other contract checking techniques, like
assertions, invariants and the like. After all the unit that a value
is measured in is part of the contract.
This is one of those features that gets proposed frequently in multiple
languages. It's a great example for metaprogramming. But, are there
examples of this idea being seriously *used* in production code in ANY
language?
(For example, does anybody actually use Boost.Unit?)
At work we use C++ enums for categorical types to great effect. The way it
works is:
enum UserId { min = 0, max = 1 << 31 };
enum AppId { min = 0, max = 1 << 31 };
then we express data in terms of UserID, AppId instead of an integral type, and
we cast to it when we read it off the wire or the database. The beauty of it is
that you can never pass by mistake an AppId instead of a UserId of vice versa,
or even a raw int as one without explicitly stating intent.
It's saved us a lot of bugs (I know because I found some when converting raw
ints to enums) and presumably potential bugs.
If we used quantities probably a similar benefit would emerge from using
dimensional analysis. I know that in my machine learning code it's very
difficult to spot bugs because "it's all numbers". If I used a sort of a double
"enum" that could only be a probability, I'm sure I'd save myself a ton of bugs.
Waow, this is a great explanation of expected benefits of units, I guess.
Also, isn't this precisely the power of true typedefs?
Denis
--
_
vita es estrany
spir.wikidot.com
Re: [GSoC Proposal] Statically Checked Measurement Units
On 03/29/2011 03:49 PM, Cristi Cobzarenco wrote:
To David:
Ok, right now, I got two working versions, one sorting by .mangleof and one
performing a double-inclusion test on the tuples. Both work, I can't see any
performance increase in the .mangleof one, but if .mangleof returns unique
string, I say we use it this way.
Regarding my string little DSL. I have 3 solutions right now:
1. Drop the DSL altogether, right now my system would work perfectly fine
with boost-like tuples (a list of units alternating with exponents):
Quantity!(Metre,1,Second,-1) speed = distance/time;
While less readable, this doesn't have the disadvantages of the following 2.
2. Use a mixin template to declare the expression parser in the current
scope:
mixin DeclareExprQuantity!();
struct Metre {}
struct Second {}
struct Kg {}
void f() {
ExprQuantity!("Metre/Second * Kg^-1") q = speed / mass;
}
This works, is readable, but it uses C-preprocessor like behaviour (read:
black vodoo) - a library declaring something in your scope isn't very nice.
3. Abandon using types as units and just use strings all the way. This
doesn't guarantee unit name uniqueness and a misspelled unit name is a new
unit. One could use an algorithm to convert all strings to a cannonical form
(like Andrei suggested) and then use string equality for unit equality.
What do you think, I'm personally quite divided:
1. I like that this is simple and it works. It make writing derived units
unnatural though.
2. I actually like this one, despite the obvious ugliness. It's just one
extra line at the beginning of your code and you can the use arithmetic
operations and use type-uniqueness to guarantee unit-uniqueness.
3. This is a bit dangerous. It works very well as long as there isn't more
than one system of units. I still like it a bit.
Have you considered
0. Derived units are declared?
After all, relative to the size of an app, and the amount of work it
represents, declaring actually used derived units is very a small burden.
This means instead of:
struct meter {}
struct second {}
auto dist = Quantity!"meter"(3.0);
auto time = Quantity!"second"(2.0);
auto speed = Quantity!"meter/second"(dist/time);
auto surface = Quantity!"meter2"(dist*dist);
one would write:
struct meter {}
struct second {}
alias FractionUnit!(meter,second) meterPerSecond;
alias PowerUnit!(meter,2) squareMeter;
auto dist = Quantity!meter(3.0);
auto time = Quantity!second(2.0);
auto speed = Quantity!meterPerSecond(dist/time);
auto surface = Quantity!squareMeter(dist*dist);
This means you use struct templates as unit-id factories, for user's
convenience. The constructor would then generate the metadata needed for
unit-type checking, strored on the struct itself (this is far more easily using
such struct templates than by parsing a string).
In addition to the 2 struct templates above, there should be
struct ProductUnit(Units...) {...}
(accepting n base units); and I guess that's all, isn't it?
The only drawback is that very complicated derived units need be constructed
step by step. But this can also be seen as an advantage. An alternative may be
to have a single, but more sophisticated and more difficult to use, struct
template.
I find several advantages to this approach:
* Simplicity (also of implementation, I guess).
* Unit identifiers are structs all along (both in code and in semantics).
* No string mixin black voodoo.
I guess even if this is not ideal, you could start with something similar,
because it looks easier and cleaner (to me).
A similar system may be used for units of diff scales in the same dimension:
alias ScaleUnit!(mm,1_000_000) km;
By the way, have you considered unit-less (pseudo-)magnitudes (I mean ratios,
including %). I would have one declared and exported as constant. then,
alias ScaleUnit!(voidUnit,0.001) perthousand;
To Don:
* Choosing one unit and using it is still a very good idea. As I said there
are to be no implicit conversions, so this system would ensure you don't, by
mistake, adhere to this convention. Also, if somebody else uses your library
maybe they assume everything is in meters when in fact you use milimeters.
Sure they should check the documentation, but it's better if they get a nice
error message "Inferred unit Meter doesn't match expected Milimeter", or
something like that.
I agree with this.
Denis
--
_
vita es estrany
spir.wikidot.com
Re: expression templates
== Quote from bearophile (bearophileh...@lycos.com)'s article > The operator overloading done with opCmp is too much coarse even if you want > to implement sets with operators like <= < > >= == for subset, etc. Can you please give an example of where <=, >, etc. are useful for representing set operations? My naive opinion (i.e. without understanding your use case) is that using comparison operators to represent anything besides partial or total ordering is a severe abuse of operator overloading. (Their use to represent ordering of corresponding elements of a vector or matrix is a borderline case.)
Re: Is D more complex than C++?
Andrej Mitrovic wrote: This is obviously the same old D troll. Stop feeding him guys. This one was a good question. Actually a very good one. Regardless of the motivation behind it.
Re: [GSoC Proposal] Statically Checked Measurement Units
On 3/29/11 2:33 PM, Cristi Cobzarenco wrote: Surely, .mangleof returns unique strings? Yes, .mangleof returns unique strings for types. The stringof property which was suggested by other people here on the NG, however, is not unique. […] Thanks a lot for your feedback, I feel this collaboration will help D in the end, no matter whose proposal gets accepted (if any). I am a bit confused regarding your GSoC proposal, aren't you a mentor? No, I'm just hoping to participate in this GSoC as a student as well. To clarify the situation: Having experienced how incredibly useful dimensional analysis is in many areas of science, I have long been interested in possible ways of using unit systems in programming to gain additional type safety. Earlier this year, before a possible application to GSoC was even brought up in the D community, I started to work on a D implementation of an unit system. I finished a working prototype, but didn't have the time yet to implement a flexible unit conversion scheme and, more importantly, extend the documentation and examples so I could put it up for discussion at the D NG. Then, it was announced that Digital Mars would participate in this Google Summer of Code, and surprisingly it didn't take long until someone added an unit system to the ideas page. As I was considering to apply to GSoC anyway, this seemed like a natural fit. However, Andrei also put up the idea of a D implementation of Apache Thrift, which caught my attention as I have been waiting for the opportunity to have an in-depth look on it for quite some time now. As I am equally interested in both topics, and students are allowed to submit a large number of proposals (20?), I decided to just write project proposals for both of them and let Walter/Andrei/… choose which one they like better, if any. I decided to start with the Thrift one, and planned to submit my units proposal later in the application period. After publishing my first draft here at the NG, I also contacted Andrei for his opinion on whether it would make sense to submit a second proposal, given that he seemed quite interested in the Thrift idea. Now, back to topic: I am absolutely sure that collaborating on this project will lead to better results (I mean, that's how open source software works after all), but there is a problem: By the GSoC rules, it's not possible for students to work in teams on a single project. The dilemma I hinted at is that if we start working together right now, we'll probably end up with two almost identical proposals/applications for the same project, which doesn't really seem desirable. Also, I'm increasingly doubtful that an units library would be a good fit for a Summer of Code project in the first place, which is also why I finished my other proposal first: As Don said, I think that while it certainly is a nice demonstration of the metaprogramming capabilities/type system expressiveness of a language, it might not be too useful for the »general public«, compared to other features. Don't get me wrong here, I'm personally very enthusiastic about the idea, and I can imagine many possible ways in which a flexible unit system could be used to avoid bugs or to clarify interfaces. But: The concept isn't new at all – for example, during my research I stumbled over papers dedicated to units in programming languages dating back to 1985 –, but I have yet to see units actually being used in production code. My second concern is the extent of the project: After spending two weekends on it, I have a working prototype of a units library, and, if I understood you correctly, you have one as well. They surely both lack some features and a lot of polish and documentation, but I think it would probably take neither of us three full months of work to get them into a state suitable for inclusion in the Phobos review queue. For these reasons, I really started to wonder if it wouldn't be the better idea to just merge our projects and work on getting the result into shape independent of GSoC when I saw your proposal – even more so since our design/implementation ideas have shown to be quite similar. I don't want to discourage you from applying at all, and I will probably still submit a proposal for it nevertheless, but I think this should be discussed. David
Re: expression templates
enuhtac: > As there are no answers related to opCmp I assume I have to use one of > my ugly workarounds... The operator overloading done with opCmp is too much coarse even if you want to implement sets with operators like <= < > >= == for subset, etc. So are two use cases enough to question the current design of D opCmp? Bye, bearophile
Re: [GSOC Draft Proposal] ANTLR and Java based D parser for IDE usage
Hello, thank you very much for your useful comments. I have updated the proposal version in the www.google-melange.com. I post here the changes and the updated version. Changes: - There are different IDEs for the D programming language. The purpose of this project proposal is to write a parser for a superset of the D programming language (including v1 and v2) that is tailored for IDEs needs. -Specifically, a good error recovery strategy is an essential feature in an IDE. The parser should be able to restore itself to a state where processing of the input can continue with reasonable hopes that further processing will provide meaningful diagnostic information. -Once I have got an overall understanding I will write the production rules of a superset of the D grammar in the ANTLR grammar notation (similar to EBNF). PROPOSAL ANTLR and Java based D parser for IDE usage === Luca Boasso Abstract The project aims to implement an ANTLR parser for the D programming language and the consequent integration with the DDT Eclipse-based IDE. The parser will be designed to be reused in other IDEs or tools. Rationale - There are different IDEs for the D programming language. The purpose of this project proposal is to write a parser for a superset of the D programming language (including v1 and v2) that is tailored for IDEs needs. The new parser will be designed to be modular and abstracted from any particular IDE implementation detail, so that it can be used in different IDEs or with tools that need an abstract syntax tree of the source code for further analysis. Particular care will be taken to integrate the new parser with the DDT Eclipse-based IDE so that this project will be useful in the short-term. The DDT project needs a new parser up-to-date with the latest D syntax, with a better error recovery and improved performance [0]. Specifically, a good error recovery strategy is an essential feature in an IDE. The parser should be able to restore itself to a state where processing of the input can continue with reasonable hopes that further processing will provide meaningful diagnostic information. Thanks to this integration it will be possible to understand the appropriate interface for the parser so that in the long-term the same code could be used in different projects. I will use the ANTLR parser generator for this project. This parser generator has been proven to be a valuable tool with advanced features for tree construction and tree manipulations that cuts development time [1]. The LL(*) parsing algorithm on which ANTLR is based upon allows efficient parsing of complex grammar with good error handling and unrestricted grammar actions [2]. The use of a parser generator allows the creations of parsers in different programming languages. This project will focus on the creation of a Java parser. Since ANTLR support many target languages [3], it will not be so difficult to generate a parser in the original implementation language of the IDE. Eg. Generate a C++ parser for the D language that will be used in the IDE written in C++. Furthermore, updates of the D grammar are reflected in a more convenient way through modifications of the ANTLR grammar of D, than through a modification of a hand-written parser. In particular, one of the problems faced by DDT developers was to keep their parser up-to-date with the reference one (DMD parser) [4]. It is time-consuming and error-prone to manually port and mantain the DMD parser written in C++ to another language, instead most of the modification will be handled by ANTLR. In addition, easy modification of the D language syntax encourages experimentation for the benefit of the language's evolution. Finally in the process of writing a new parser eventual misunderstanding or inconsistency of the D language reference and documentations will be addressed. A good set of test will be created to guarantee the compatibility of the new parser with the official language definition and the DMD parser. Timeline This is a tentative timeline to be further discussed with the help of the community. I am committed to dedicate substantially to this project knowing that I also have to pass some exams. I estimate that I could spend initially approximately 30h/week. After the exam session I will work full-time on this project. - April 25 – May 23: Community Bonding Period Since I am new in the D community I will spend some time learning how to contribute while following the guideline of the community and the DDT project. I will start reviewing the language reference asking for clarifications when needed. Once I have got an overall understanding I will write the production rules of a superset of the D grammar in the ANTLR grammar notation (similar to EBNF). - May 23 – July 11: Developing phase I The correctness of the parser is of paramount importance. I will create many tests to exercise the
Re: expression templates
Am 29.03.2011 20:16, schrieb Caligo: > enuhtac, may I ask what you are going to use the expression templates > for? linear algebra library? is it an open source project? Hi Caligo, I'm going to use the expression templates for CFD (computational fluid dynamics) computations. In this context I need to implement linear and nonlinear operators on 2D and/or 3D variable fields (in my case based on expression templates). It this will not result in a classical linear algebra package but it will include some of its features - i.e. simple algebraic operations on vectors and the solution of sparse linear equation systems. Concerning the type of project: first of all I'm playing around a bit, to see what D has to offer and to refine my ideas of an CFD framework. If things develop well this may lead to an open source project. We'll see... As there are no answers related to opCmp I assume I have to use one of my ugly workarounds... enuhtac
Re: GSoC-2011 project:: Containers
>I can try to answer your questions, but I have not applied to be an >official mentor. Just want to make that clear. > >My previous message was "I would be a mentor for this, but (reasons why I >will not)" > >Sorry if that is not what you read. > >-Steve That's ok, You have given me enough encouragement to carry on this project. :-) - The project idea page gives only a brief introduction to the project. From the ongoing conversation in this mailing list I feel that different people different expectations from this project. But it is hard to make everyone happy. (Me my self being new to will need more time to get familiar with the advanced concepts of D.) So I want to know what are the containers that you hope me to implement in phobos? Thank you...!
Re: expression templates
enuhtac, may I ask what you are going to use the expression templates for? linear algebra library? is it an open source project?
Re: CTFE Overhaul (Was: RFC: Thrift project proposal (draft))
On 3/27/11, Andrej Mitrovic wrote: > I remember a few months ago I've tried using CTFE and import > expressions to load a .def file and generate at compile-time a runtime > DLL loading mechanism in a class which would load a DLL file and > create wrapper functions for DLL functions. Found it. It doesn't actually load a .def file, and it wouldn't make much sense since a def file doesn't have much except a list of symbol names. It generates code that links function pointers to a DLL at runtime, and creates wrapper functions which take care of calling the C code. First I'd create a struct with a list of function prototypes. Then I'd just mixin() a string inside a class. The function that creates the string to be mixed in first checks the return values of the function prototypes, and based on that it can add code that throws on invalid values. Here's an example of a generated class at compile-time: https://gist.github.com/892698 or if that doesn't display right: http://dl.dropbox.com/u/9218759/result.d Of course much more could be done here. The generated functions could take strings instead of char pointers and call toStringz on them when calling a function pointer. And we could use ref instead of pointers for other parameters.
Re: expression templates
On Tue, 29 Mar 2011 08:24:01 -0400, enuhtac wrote: Am 28.03.2011 02:19, schrieb Robert Jacques: Hmm... I don't know you're use case exactly, but it sounds like a case of operator overload abuse. The design of opCmp was inspired by the amount of bug prone repetition that happens with C++ style comparison operators. Furthermore, both opCmp and opEquals have fixed return types in order to limit abuse. (D also prevents the overload of certain operators for the same reason). The main reason behind expression templates is to avoid costly intermediates, but the expression is always going to be heavier weight than an int, so why can't you evaluated the expression then and there? If my usage of opCmp is an overload abuse then expression templates are an abuse of D. Maybe this is true, I'm not sure. Clearly opCmp and opEquals were not designed with expression templates in mind. What I would like to achieve is to generate source code from an expression. E.g.: expression: lapl[I,J] = (v[I-1,J] + v[I+1,J] + v[I,J-1] + v[I,J+1]) / h^^2 generated source code: for( j = 0; j < ny; ++j ) for( i = 0; i < nx; ++i ) lap[idx(i,j)] = (v[idx(i-1,j)] + v[idx(i+1,j)] + v[idx(i,j-1)] + v[idx(i,j+1)]) / h^^2; If this is D source code it can be immediately be compiled using mixin(). But it is not necessarily D source code, it could also be OpenCL source code for example. So I'm trying to implement an abstraction layer that enables me to formulate expressions and algorithms independant from the the device they are executed on. A software written on top of this abtraction layer would run on CPU or GPU without any modifications. Of course it is necessary to pass some additional hints about the structure of the expression to the code generator to enable specific optimizations - but I think this can be easily done. The first step to implement such a framework is to parse the expression. I thought expression templates would be the easiest way to do so (as compared to string parsing). Also this automatically ensures that parsing is done at compile time which is necessary for the use of mixin() of course. Although not shown above I definitely need comparison operators for the algorithms I would like to implement (e.g. Godunov type advection schemes for the simulation of compressible fluid flows). Regards, enuhtac Makes sense. I think, particularly if you're thinking about targeting OpenCl, etc, than instead of using <=, etc, you should use a higher order primitive, like min, filter or map, as this information becomes critical to implementation selection. I've used vectorized booleans in Matlab before, and found that while the syntax is short and sweet, the usage is always a shortcut to another concept.
Re: Curl support RFC
Jonas Drewsen wrote: > >This is a nice protocol parser. I would very much like it to be used >with the curl API but without it being a dependency. This is already >possible now using the onReceiveHeader callback and this would >decouple the two. At least until std.protocol.http is in phobos as >well - at that point convenience methods could be added :) > >/Jonas Thanks, I think I'll propose the parser for the new experimental namespace when it's available. About the headersReceived callback: You're totally right, it can be done with the onReceiveHeader callback right now. But I think in the common case the user wants the headers in an key/value array. So if the user doesn't want to use the onReceiveHeader api, a headersReceived callback would probably be convenient. But, as said it's not necessary. Reading the curl documentation showed another small trap: CURLOPT_HEADERFUNCTION It's important to note that the callback will be invoked for the headers of all responses received after initiating a request and not just the final response. This includes all responses which occur during authentication negotiation. If you need to operate on only the headers from the final response, you will need to collect headers in the callback yourself and use HTTP status lines, for example, to delimit response boundaries. I think if we store the headers into an array, we should only store the headers of the final response. Another question is should all headers or only final headers trigger the onReceiveHeader callback? Passing only the final headers would require extra work, passing all headers should at least be documented. Thinking of this more, this also means the _receiveHeaderCallback is not 100% correct, as it expects all lines after the first line to be header or empty lines, but it's possible that we get multiple statuslines. It still works, the regex doesn't match anything and the code ignores that line. But this way, the stored statusline will always be the first statusline, which isn't optimal. We'd also need to detect if a line is a statusline to reset the headers array if it's used. Seems like we have to think about this some more. -- Johannes Pfau signature.asc Description: PGP signature
Re: Bruno Medeiros has been accepted as a GSoC 2011 mentor for Digital Mars
On 03/29/2011 07:46 AM, Steven Schveighoffer wrote: On Tue, 29 Mar 2011 08:04:00 -0400, Bruno Medeiros wrote: On 27/03/2011 19:57, Andrei Alexandrescu wrote: Bruno Medeiros from Google has been accepted as a mentor for the Google Summer of Code 2011 program for Digital Mars. Please join me in congratulating and wishing the best to Bruno. We have three mentors and two pending applications. We are always looking for mentor and student applications. Please refer to this page for how to apply: http://d-programming-language.org/gsoc2011.html Andrei Thanks. I hope to do a good job if indeed any IDE related proposals get accepted. BTW, that page lists me are working for Google, but that is incorrect, not sure what gave you that idea (I wish it were true though :P ) I had that impression too. There was a post you made a while back where I thought you suggested quite subtly that you work for them. But I can't find it now (unfortunately my browser doesn't support the "find all messages which made me think Bruno Medeiros works for google" search feature). -Steve It's simply that Bruno and I last met at my Google tech talk. Andrei
Re: [GSoC Proposal] Statically Checked Measurement Units
On 03/29/2011 07:36 AM, Don wrote: I'm a physicist and most of my programming involves quantities which have units. Yet, I can't really imagine myself using a units library. A few observations from my own code: * For each dimension, choose a unit, and use it throughout the code. For example, my code always uses mm because it's a natural size for the work I do. Mixing (say) cm and m is always a design mistake. Scaling should happen only at input and output, not in internal calculations. (So my feeling is, that the value of a units library would come from keeping track of dimension rather than scale). Many of my bugs involving numeric code is that I mix scalars with units, not units of different scale. Andrei
Re: i like cakes
On 03/29/2011 07:14 AM, Bruno Medeiros wrote: On 28/03/2011 10:03, Alix Pexton wrote: try this? Dealing with Internet Trolls - the Cognitive Therapy Approach http://unarmed.shlomifish.org/909.html A... Ha, I saw that article recently, I think it may work for overly excited fanboys, or for people involved in a flame war, but not for trolls. In other words I think it only works for people honest with their intentions (even if very emotional about it), but not with people deliberately spreading confusion, FUD, or just getting a kick out of being a troll. (Disclaimer: I only skimmed it.) That must deal with the emotional reaction to trolling, but I have none. The only issue is that one individual is manipulating the system at reddit to spread disinformation. In addition, he is obsessively following Walter and finding fault with every word he says. We just need a principled approach to solving this problem. (When I'll find some time I'll do some stylometry - I'll create a language model from iliekcaeks' past texts and run it through parametricpoly's text. The styles are extremely similar and a language model will catch that. If the obtained perplexity is low, then that is indicative of socket puppetry. Not that that would be an Earth-shattering discovery :o).) I posted this last night in http://www.reddit.com/r/programming/comments/gcmj1/digital_mars_aka_the_d_programming_language/: = Registration is open for students starting today. Apply at the same location. We already have a strong lineup of mentors, projects, and students, and we're always looking for more. Good luck! = When I downvote a post, I do so if it's factually incorrect or trolling. By that standard one would hardly find the above off-topic inside a thread about D's participation to GSoC 2011. Yet this morning the post was buried at the end of the thread with 13 downvotes canceling 14 upvotes. This is particularly cynical because at the end of the day it's about some students making some money through the summer working on something they find fun. If e.g. the competing language Go would have a summer of code proposal and discussion, I'd find it heinous of me to try to make that information disappear or otherwise drive people away. Also, the GtkD announcement I made last night was deleted. I just emailed moderators about it. Leaving aside the fact that I'm doing what the authors of GtkD ought to be doing, I suspect moderators would automatically or semi-automatically delete a post if 10-20 users would click on "spam" for it. It's possible some socket puppets have been hard at work last night. Andrei
Re: Pretty please: Named arguments
On 24/03/2011 20:23, Steven Schveighoffer wrote: P.S. I've tried two D ides in the past for about 10 minutes (descent and code::blocks), could not get either of them to work right. And it was *not* trivial to set them up. I must invite you try out DDT :D , even you don't stick to using it aferward. It should be no more than 5 minutes to setup (download times excluding): http://code.google.com/a/eclipselabs.org/p/ddt/wiki/UserGuide *fingers crossed* -- Bruno Medeiros - Software Engineer
Re: [GSOC Draft Proposal] ANTLR and Java based D parser for IDE usage
On 28/03/2011 01:52, Luca Boasso wrote:
Sorry for my late draft proposal, I'm currently moving so I didn't
have enough time this days.
I would be glad to have your opinion.
Thank you
Rationale
-
There are different IDEs for the D programming language. The purpose of this
project proposal is to write a parser for the D programming language (v1 and v2)
that is tailored for IDEs needs. The new parser will be designed to be modular
and abstracted from any particular IDE implementation detail, so that it can be
used in different IDEs or with tools that need an abstract syntax tree of the
source code for further analysis.
Particular care will be taken to integrate the new parser with the DDT
Eclipse-based IDE so that this project will be useful in the short-term.
>
The DDT project needs a new parser up-to-date with the latest D syntax, with
a better error recovery and improved performance.
Thanks to this integration it will be possible to understand the appropriate
interface for the parser so that in the long-term the same code could be used in
different projects.
I will use the ANTLR parser generator for this project. This parser generator
has been proven to be a valuable tool with advanced features for tree
construction and tree manipulations that cuts development time [1]. The LL(*)
parsing algorithm on which ANTLR is based upon allows efficient parsing of
complex grammar with good error handling and unrestricted grammar actions [2].
The use of a parser generator allows the creations of parsers in different
programming languages. This project will focus on the creation of a Java parser.
Since ANTLR support many target languages [3], it will not be so difficult to
generate a parser in the original implementation language of the IDE.
Eg. Generate a C++ parser for the D language that will be used in the IDE
written in C++.
Furthermore, updates of the D grammar are reflected in a more convenient way
through modifications of the ANTLR grammar of D, than through a modification of
a hand-written parser.
In particular, one of the problems faced by DDT developers was to keep their
parser up-to-date with the reference one (DMD parser) [4].
It is time-consuming and error-prone to manually port the DMD parser written in
C++ to another language, instead most of the modification will be handled by
ANTLR.
In addition, easy modification of the D language syntax encourages
experimentation for the benefit of the language's evolution.
Finally in the process of writing a new parser eventual misunderstanding or
inconsistency of the D language reference and documentations will be addressed.
A good set of test will be created to guarantee the compatibility of the new
parser with the official language definition and the DMD parser.
Like Andrei said, and as is already mentioned in this proposal, I think
the focus of this parser project should to integrate with DDT, so that
we can have something directly useful at the conclusion of the project.
And also to validate that the parser is worthwhile for IDE usage.
Fortunately this is not contrary to the other goals of making the
grammar reusable for other ANTLR-based parsers coded in another
language, or to make the D parser reusable in other Java-based projects.
The DDT AST classes (and the basic semantic engine) are already isolated
in their own bundle/module, conceptually independent of any Eclipse code
(there a few minor coded dependencies that are trivially removable).
The proposal text looks good to me, but one missing thing that I think
is key to consider is error recovery. The current parser (Descent/DMD)
is already fairly good at this, (although it could be improved in some
regards). The new ANTLR parser would not need to be as good as DMD, but
it should have good recovery at least in same basic IDE usage cases. So
for example:
/* block structure stuff: */
void func() {
blah(
}
// the parser should still recover successfully and parse the rest of //
the file after func
Recovery inside statements, and some other use cases are also very
important, but this can be discussed in more detail later, my point now
is just that the consideration of the syntax recovery should be present
to the proposal. (just mention it, no need to write much about it)
Some other comments relating to implementation and design details:
Once I have got an overall understanding I will write the production
rules of the D grammar (v1 and v2) in the ANTLR grammar notation (similar to
EBNF).
Hum, I am inclined to think that having two separate grammars for each
version of D is not the best approach. For starters, even for D2 there
are not one, but many version of the language, even with regards to just
parsing D2. True, we may choose to not support those previous versions,
and focus only on D2 as of TDPL, but it is still important to be mindful
of this. Also because there might be additions to the syntax of D2.
And here IDE development diffe
Re: Bruno Medeiros has been accepted as a GSoC 2011 mentor for Digital Mars
On 03/29/2011 07:04 AM, Bruno Medeiros wrote: On 27/03/2011 19:57, Andrei Alexandrescu wrote: Bruno Medeiros from Google has been accepted as a mentor for the Google Summer of Code 2011 program for Digital Mars. Please join me in congratulating and wishing the best to Bruno. We have three mentors and two pending applications. We are always looking for mentor and student applications. Please refer to this page for how to apply: http://d-programming-language.org/gsoc2011.html Andrei Thanks. I hope to do a good job if indeed any IDE related proposals get accepted. BTW, that page lists me are working for Google, but that is incorrect, not sure what gave you that idea (I wish it were true though :P ) Sorry. Please email me your affiliation so I put it in there. Andrei
Re: [GSoC Proposal] Statically Checked Measurement Units
On 03/29/2011 02:06 AM, Don wrote:
Cristi Cobzarenco wrote:
First, let me apologize for this very late entry, it's the end of
university and it's been a very busy period, I hope you will still
consider it.
Note this email is best read using a fixed font.
PS: I'm really sorry if this is the wrong mailing list to post and I
hope you'll forgive me if that's the case.
=== Google Summer of Code Proposal: Statically Checked Units ===
Abstract
-
Measurement units allow to statically check the correctness of
assignments and expressions at virtually no performance cost and very
little extra effort. When it comes to physics the advantages are
obvious – if you try to assign a force a variable measuring distance,
you've most certainly got a formula wrong somewhere along the way.
Also, showing a sensor measurement in gallons on a litre display that
keeps track of the remaining fuel of a plane (a big no-no) is easily
avoidable with this technique. What this translates is that one more
of the many hidden assumptions in source code is made visible: units
naturally complement other contract checking techniques, like
assertions, invariants and the like. After all the unit that a value
is measured in is part of the contract.
This is one of those features that gets proposed frequently in multiple
languages. It's a great example for metaprogramming. But, are there
examples of this idea being seriously *used* in production code in ANY
language?
(For example, does anybody actually use Boost.Unit?)
At work we use C++ enums for categorical types to great effect. The way
it works is:
enum UserId { min = 0, max = 1 << 31 };
enum AppId { min = 0, max = 1 << 31 };
then we express data in terms of UserID, AppId instead of an integral
type, and we cast to it when we read it off the wire or the database.
The beauty of it is that you can never pass by mistake an AppId instead
of a UserId of vice versa, or even a raw int as one without explicitly
stating intent.
It's saved us a lot of bugs (I know because I found some when converting
raw ints to enums) and presumably potential bugs.
If we used quantities probably a similar benefit would emerge from using
dimensional analysis. I know that in my machine learning code it's very
difficult to spot bugs because "it's all numbers". If I used a sort of a
double "enum" that could only be a probability, I'm sure I'd save myself
a ton of bugs.
Andrei
Re: GCC 4.6
== Quote from Don (nos...@nospam.com)'s article > dsimcha wrote: > > On 3/28/2011 9:54 PM, jasonw wrote: > >> Listen kid, you're some biology student, right? You're just coding for > >> fun. And more importantly, you haven't participated in any long term > >> real world systems programming projects. This kind of work experience > >> doesn't give you the competence to evaluate the knowledge and work of > >> people with tens of years of programming experience under their belt. > >> > >> You might be terribly smart, but you're missing the point. Can you see > >> what we are building here? A whole language ecosystem. Andrei has done > >> great work by attracting competent CS persons in to the community. > > > > While I think some good points were raised here, I find the implication > > that biologists and generally non-CS people can't do first rate > > programming mildly offensive. Formal education in CS helps especially > > when doing CS research, but it's not a requirement for being a "real" > > programmer. I'm a biomedical engineering student and primarily write > > research and hobby code, not industrial code. Walter's degree is in > > mechanical engineering and he's one of the best programmers I can think > > of. Heck, even Andrei didn't have a formal degree in CS until recently. > > (His undergrad, IIRC, is in electrical engineering.) > I have a physics degree, and have worked in solar photovoltaics for > fifteen years. I'd have put you in my original post, too if I had known more detail about your background. Generally I think having non-CS people heavily involved in D's design helps immensely rather than hurting. CS people are great when you need something with strong theoretical underpinnings, but some things require a different, more real-world implementation and use case oriented mindset. I'm not saying CS people **can't** think this way, just that it's not the primary way they're **trained** to think. Having people with natural science and engineering backgrounds involved prevents D from becoming too ivory-tower. I also think it's a positive feedback loop: D refuses to compromise practicality to satisfy the Higher Principles of Computer Science, thus it attracts scientists and engineers who are more interested in practicality than the Higher Principles of Computer Science. Ironically, this branch started with a discussion about Bearophile's posts and despite his biology background I find most of them too ivory-tower.
Re: Is D more complex than C++?
This is obviously the same old D troll. Stop feeding him guys.
Re: Complete D grammar
Rainer Schuetze Wrote: > I've set up a comparison with some notes here: > > http://www.dsource.org/projects/visuald/wiki/GrammarComparison Very nice comparison style. What would be an appropriate way to discuss grammar changes? I think many things should be simplified/clarified. For example, isn't AutoDeclaration already covered by Decl -> StorageClasses Decl and so on? Also there are 3 different instances of mixin: MixinExpression, MixinStatement and MixinDeclaration. Even though they all come down to the same thing. Modifiers like shared are repeated, e.g. in BasicType, Attribute, TypeSpecialization. Also your proposed TypeWithModifier somewhat replicates parts of BasicType (just without the parentheses)
Re: [GSoC Proposal] Statically Checked Measurement Units
To David:
Ok, right now, I got two working versions, one sorting by .mangleof and one
performing a double-inclusion test on the tuples. Both work, I can't see any
performance increase in the .mangleof one, but if .mangleof returns unique
string, I say we use it this way.
Regarding my string little DSL. I have 3 solutions right now:
1. Drop the DSL altogether, right now my system would work perfectly fine
with boost-like tuples (a list of units alternating with exponents):
Quantity!(Metre,1,Second,-1) speed = distance/time;
While less readable, this doesn't have the disadvantages of the following 2.
2. Use a mixin template to declare the expression parser in the current
scope:
mixin DeclareExprQuantity!();
struct Metre {}
struct Second {}
struct Kg {}
void f() {
ExprQuantity!("Metre/Second * Kg^-1") q = speed / mass;
}
This works, is readable, but it uses C-preprocessor like behaviour (read:
black vodoo) - a library declaring something in your scope isn't very nice.
3. Abandon using types as units and just use strings all the way. This
doesn't guarantee unit name uniqueness and a misspelled unit name is a new
unit. One could use an algorithm to convert all strings to a cannonical form
(like Andrei suggested) and then use string equality for unit equality.
What do you think, I'm personally quite divided:
1. I like that this is simple and it works. It make writing derived units
unnatural though.
2. I actually like this one, despite the obvious ugliness. It's just one
extra line at the beginning of your code and you can the use arithmetic
operations and use type-uniqueness to guarantee unit-uniqueness.
3. This is a bit dangerous. It works very well as long as there isn't more
than one system of units. I still like it a bit.
The only completely clean alternative would be the abominable:
Quantity!( mixin(Expr!("Metre/Second")) ) q;
To Don:
* Choosing one unit and using it is still a very good idea. As I said there
are to be no implicit conversions, so this system would ensure you don't, by
mistake, adhere to this convention. Also, if somebody else uses your library
maybe they assume everything is in meters when in fact you use milimeters.
Sure they should check the documentation, but it's better if they get a nice
error message "Inferred unit Meter doesn't match expected Milimeter", or
something like that.
* True, scale errors can be figured out easily, multiplying something with
an acceleration instead of velocity, or forgetting to multiply acceleration
by a timestep isn't as easily checked. Multiplying instead of dividing in a
formula, or forgetting to divide by a normalisation constant are other
things you may forget, and are caught instantly by unit checking.
* Arrays & vectors are very important, I agree. The Quantity! type is
parametrised both by a unit and a value type, therefore, if one wants a
vector whose components are of the same unit, using "Quantity!(Metre,
Vector!(double))" would work. Vector!(Quantity!(Metre,double)) would also
work. As long as the value type has arithmetic operations defined everything
works out. Same goes for arrays.
There is a risk that it never gets used, sure. But I think that units will
become commonplace, some time in the future, so while it won't get wide
acceptance very soon, at some point people will be looking on Wikipedia for
"Languages supporting measurement units" and it will be good for D to show
up there.
On 29 March 2011 14:36, Don wrote:
> Cristi Cobzarenco wrote:
>
>> To Don:
>> That is a very good point and I agree that one shouldn't implement
>> features just because they're popular. There don't seem to be many (if any
>> projects) using Boost.Units and only a few that use the feature in F#.
>> But, I think the reason Boost.Units isn't use hasn't got much to do with
>> the idea as much as it does with the implementation. Using units in Boost is
>> very cumbersome. Adding new units (measuring different dimensions)
>> on-the-fly is virtually impossible. I think that that Boost.Units misses the
>> point of units. They should be a natural extension of the type system of a
>> language, not something so limited to the area of natural sciences. D is a
>> new language and we should be pushing the envelope, just because the Boost
>> failed (if it did, it may very well kick-off later) doesn't mean we
>> shouldn't do it. Since it is such a new feature, I think we should talk
>> about its potential rather than its acceptance.
>> When it comes to F#, I think the reason there aren't many projects using
>> units is because there aren't many projects in F# period. It is a very
>> popular feature in the F# community (judging by blog posts and the like) and
>> people are still trying to figure out exactly how to use it. I feel that in
>> F#, it has the potential to become very widely used once people agree on
>> some conventions and good practices.
>> As I said in the abstract, I think the feature fits snugly with other
>> mechanisms in D and seems to be
Re: Complete D grammar
spir Wrote: > Sure, and this grammar should be the actual startpoint of actual parsers, so > that we know it's correct ;-) (else, it's just some more blowing in the wind) Exactly!
Re: Bruno Medeiros has been accepted as a GSoC 2011 mentor for Digital Mars
On 29/03/2011 13:46, Steven Schveighoffer wrote: On Tue, 29 Mar 2011 08:04:00 -0400, Bruno Medeiros wrote: On 27/03/2011 19:57, Andrei Alexandrescu wrote: Bruno Medeiros from Google has been accepted as a mentor for the Google Summer of Code 2011 program for Digital Mars. Please join me in congratulating and wishing the best to Bruno. We have three mentors and two pending applications. We are always looking for mentor and student applications. Please refer to this page for how to apply: http://d-programming-language.org/gsoc2011.html Andrei Thanks. I hope to do a good job if indeed any IDE related proposals get accepted. BTW, that page lists me are working for Google, but that is incorrect, not sure what gave you that idea (I wish it were true though :P ) I had that impression too. There was a post you made a while back where I thought you suggested quite subtly that you work for them. But I can't find it now (unfortunately my browser doesn't support the "find all messages which made me think Bruno Medeiros works for google" search feature). -Steve Hum, I did apply to Google on August last year (went as far as the onsite interview), and tweeted about it, but also that I wasn't accepted. :P But here on the NG I'm not sure what might have given that impression. I'm a bit of Google fan, but then again, who isn't? *cheeky* -- Bruno Medeiros - Software Engineer
Re: [GSOC idea] enhance regular expressions?
On 03/29/2011 02:16 PM, KennyTM~ wrote: On Mar 29, 11 18:56, bearophile wrote: Dmitry Olshansky: Others (except (?P) and (?P=name) ) also considered common extensions and I planed to add them plus regex comment (#...) where all of ... simply have no effect on matching. Beside the (#...) comments in Python you have also the verbose regex, that allow to put whispace and free #... comments with no parentheses. I find this one of the nicest features, because it allows you to format your regex. Bye, bearophile You can also format regex with r"\d+" // matches the integer part ~ r"(?:\.\d+)?"; // matches the fractional part :) Nice trick, thank you! Denis -- _ vita es estrany spir.wikidot.com
Re: [GSOC idea] enhance regular expressions?
On 03/29/2011 12:56 PM, bearophile wrote: Dmitry Olshansky: Others (except (?P) and (?P=name) ) also considered common extensions and I planed to add them plus regex comment (#...) where all of ... simply have no effect on matching. Beside the (#...) comments in Python you have also the verbose regex, that allow to put whispace and free #... comments with no parentheses. I find this one of the nicest features, because it allows you to format your regex. Same for me. That the feature #1 of python regexes. valuePattern = r""" [a-zA-Z][a-zA-Z0-9]* | # symbol or [+-]?[0-9]+(\.[0-9]+)? # number """ Denis -- _ vita es estrany spir.wikidot.com
Re: GCC 4.6
On 3/29/2011 3:00 AM, Russel Winder wrote: Which leads to the real point as to why Python is becoming the leading language for scientific computing, it is a dynamic language for coordinating C/C++/Fortran computations and providing GUI front ends. Performance of Python is thus a side issue since grunt computation is done in languages which are closer to the machine -- with all the crap that entails. The problem with this is when you're the poor bastard that has to write said C/C++/Fortran code, or when you want to pass complex object graphs between the languages.
Re: GCC 4.6
On 03/29/2011 07:47 AM, Don wrote: dsimcha wrote: On 3/28/2011 9:54 PM, jasonw wrote: Listen kid, you're some biology student, right? You're just coding for fun. And more importantly, you haven't participated in any long term real world systems programming projects. This kind of work experience doesn't give you the competence to evaluate the knowledge and work of people with tens of years of programming experience under their belt. You might be terribly smart, but you're missing the point. Can you see what we are building here? A whole language ecosystem. Andrei has done great work by attracting competent CS persons in to the community. While I think some good points were raised here, I find the implication that biologists and generally non-CS people can't do first rate programming mildly offensive. Formal education in CS helps especially when doing CS research, but it's not a requirement for being a "real" programmer. I'm a biomedical engineering student and primarily write research and hobby code, not industrial code. Walter's degree is in mechanical engineering and he's one of the best programmers I can think of. Heck, even Andrei didn't have a formal degree in CS until recently. (His undergrad, IIRC, is in electrical engineering.) I have a physics degree, and have worked in solar photovoltaics for fifteen years. I have a degree in "technical training" (dunno proper english term, if any), specialised in automation. Seems I'm the closer one to CS/programming here ;-) (while in a highly specialised area) But certainly one of the least competent in those fields :-( Learning every day, though. Denis -- _ vita es estrany spir.wikidot.com
Re: Complete D grammar
On 28/03/2011 18:19, Luca Boasso wrote: You can find an ANTLR grammar for D v1 at http://www.dsource.org/projects/antlrd/browser/toys/v3d/parsed.g (by Ellery Newcomer) The syntax is similar to EBNF, check the ANTLR documentation for details. I hope this might help you. Luca Boasso Indeed, Ellery is (AFAIK) the only one who has worked on ANLTR-based D parser recently and possibly got any significant work done in that. It's definitely worth looking at his work and see if anything can be reused. However, according to his most recent message on the subject: " Been pretty busy this semester, so I haven't been doing much. But the bottom line is, yes I have working antlr grammars for D1 and D2 if you don't mind 1) they're slow 2) they're tied to a hacked-out version of the netbeans fork of ANTLR2 3) they're tied to some custom java code 4) I haven't been keeping the tree grammars so up to date " http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=122803 ...it may not provide much of head-start. -- Bruno Medeiros - Software Engineer
Re: Complete D grammar
Nick Sabalausky wrote: ... > > Yea, I remember that too. Someone took all the BNF sections from D's docs > on digitalmars.com, put them together, and filled in some > missing/erroneous parts. Maybe it's on wiki4d? Not sure if this is what you meant, but Jascha Wetzel had made a D grammar used by seatd / APaGeD: http://seatd.mainia.de/grammar.html
Re: Bruno Medeiros has been accepted as a GSoC 2011 mentor for Digital Mars
On Tue, 29 Mar 2011 08:04:00 -0400, Bruno Medeiros wrote: On 27/03/2011 19:57, Andrei Alexandrescu wrote: Bruno Medeiros from Google has been accepted as a mentor for the Google Summer of Code 2011 program for Digital Mars. Please join me in congratulating and wishing the best to Bruno. We have three mentors and two pending applications. We are always looking for mentor and student applications. Please refer to this page for how to apply: http://d-programming-language.org/gsoc2011.html Andrei Thanks. I hope to do a good job if indeed any IDE related proposals get accepted. BTW, that page lists me are working for Google, but that is incorrect, not sure what gave you that idea (I wish it were true though :P ) I had that impression too. There was a post you made a while back where I thought you suggested quite subtly that you work for them. But I can't find it now (unfortunately my browser doesn't support the "find all messages which made me think Bruno Medeiros works for google" search feature). -Steve
Re: Complete D grammar
On 03/29/2011 01:02 PM, Trass3r wrote: Rainer Schuetze wrote: I've extracted the website grammar using some combination of scripts from the ddoc sources, so if there is interest, I can dig them up... Yep, please make them publicly available so they don't get lost. Though I think we should have an extra official page with the complete grammar in addition to the widespread snippets anyway. Sure, and this grammar should be the actual startpoint of actual parsers, so that we know it's correct ;-) (else, it's just some more blowing in the wind) Denis -- _ vita es estrany spir.wikidot.com
Re: [GSoC Proposal] Statically Checked Measurement Units
Cristi Cobzarenco wrote: To Don: That is a very good point and I agree that one shouldn't implement features just because they're popular. There don't seem to be many (if any projects) using Boost.Units and only a few that use the feature in F#. But, I think the reason Boost.Units isn't use hasn't got much to do with the idea as much as it does with the implementation. Using units in Boost is very cumbersome. Adding new units (measuring different dimensions) on-the-fly is virtually impossible. I think that that Boost.Units misses the point of units. They should be a natural extension of the type system of a language, not something so limited to the area of natural sciences. D is a new language and we should be pushing the envelope, just because the Boost failed (if it did, it may very well kick-off later) doesn't mean we shouldn't do it. Since it is such a new feature, I think we should talk about its potential rather than its acceptance. When it comes to F#, I think the reason there aren't many projects using units is because there aren't many projects in F# period. It is a very popular feature in the F# community (judging by blog posts and the like) and people are still trying to figure out exactly how to use it. I feel that in F#, it has the potential to become very widely used once people agree on some conventions and good practices. As I said in the abstract, I think the feature fits snugly with other mechanisms in D and seems to be a natural part of a contract-based design, so D programmers should have a predisposition (that C++ programmers might not have) of adopting such a feature. I really hope this doesn't come off as rude; as I said, you make a very good point, one that needs answering. I guess what I'm saying can be summed up as: it is a new feature; there have been mistakes; it has a lot of potential and we can make it better. I'd be curious to hear what you think. I'm a physicist and most of my programming involves quantities which have units. Yet, I can't really imagine myself using a units library. A few observations from my own code: * For each dimension, choose a unit, and use it throughout the code. For example, my code always uses mm because it's a natural size for the work I do. Mixing (say) cm and m is always a design mistake. Scaling should happen only at input and output, not in internal calculations. (So my feeling is, that the value of a units library would come from keeping track of dimension rather than scale). * Most errors involving units can, in my experience, easily be flushed out with a couple of unit tests. This is particularly true of scale errors. The important use cases would be situations where that isn't true. * Arrays are very important. Although an example may have force = mass * accelaration, in real code mass won't be a double, it'll be an array of doubles. > Since it is > such a new feature, I think we should talk about its potential rather > than its acceptance. I'm really glad you've said that. It's important to be clear that doing a perfect job on this project does not necessarily mean that we end up with a widely used library. You might be right that the implementations have held back widespread use -- I just see a significant risk that we end up with an elegant, well written library that never gets used. If the author is aware of that risk, it's OK. If not, it would be a very depressing thing to discover after the project was completed.
Re: [GSoC Proposal] Statically Checked Measurement Units
Surely, .mangleof returns unique strings? Thanks for your offer, but in my
prototype I already have sorting and operators working. You're right, again,
about the scope of the types, I have a few ideas on how to work around that,
but I don't like any of them too much, I'll play around with them and tell
you more. Thanks a lot for your feedback, I feel this collaboration will
help D in the end, no matter whose proposal gets accepted (if any). I am a
bit confused regarding your GSoC proposal, aren't you a mentor?
On 29 March 2011 13:51, David Nadlinger wrote:
> I am in a slight dilemma, because although I would love to share my work
> and ideas with you, right now this would automatically weaken my own units
> proposal in comparison to yours. However, as this would be grossly against
> the open source spirit, and the point of GSoC certainly can't be to
> encourage that, I'll just do it anyway.
>
> Regarding IDs: As I wrote in my previous post, the only point of the unit
> IDs in Boost.Units is to provide a strict total order over the set of units.
> If you can achieve it without that (see below), you won't need any
> artificial numbers which you have to manage.
>
> But why would you need to be able to sort the base units in the first
> place? The answer is simple: To define a single type representation for each
> possible unit, i.e. to implement type canonicalization. To illustrate this
> point, consider the following (pseudocode) example:
>
> auto force = 5.0 * newton;
> auto distance = 3.0 * meter;
> Quantity!(Newton, Meter) torque = force * distance;
> torque = distance * force;
>
> Both of the assignments to »torque« should obviously work, because the
> types of »force * distance« and »distance * force« are semantically the
> same. In a naïve implementation, however, the actual types would be
> different because the pairs of base units and exponents would be arranged in
> a different order, so at least one of the assignments would lead to type
> mismatch – because a tuple of units is, well, a tuple and not an (unordered)
> set.
>
> And this is exactly where the strictly ordered IDs enter the scheme. By
> using them to sort the base unit/exponent pairs, you can guarantee that
> quantities semantically equivalent always end up with the same »physical«
> type.
>
> Luckily, there is no need to require the user to manually assign sortable,
> unique IDs to each base type because we can access the mangled names of
> types at compile time, which fulfill these requirements. There are probably
> other feasible approaches as well, but using them worked out well for me
> (you can't rely on .stringof to give unique strings). When implementing the
> type sorting code, you might probably run into some difficulties and/or CTFE
> bugs, feel free to contact me for related questions (as I have already
> wasted enough time on this to get a working solution…^^).
>
> Regarding strings: I might not have expressed my doubts clearly, but I
> didn't assume that your proposed system would use strings as internal
> representation at all. What I meant is that I don't see a way how, given
> »Quantity!("Widgets/Gadgets")«, to get the Widget and Gadget types in scope
> inside Quantity. Incidentally, this is exactly the reason for which you
> can't use arbitrary functions/types in the »string lambdas« from
> std.algorithm.
>
> David
>
>
>
> On 3/28/11 9:43 PM, Cristi Cobzarenco wrote:
>
>> - I too was playing around with a units project before GSoC, that is why
>> I thought doing this project was a good idea. The way I was doing it
>> without numerical IDs was simply by having more complicated algorithms
>> for equality, multiplications etc. For example, equality would be
>> implemented as:
>> template UnitTuple(P...) {
>> alias P Units;
>> }
>>
>> template contains( Unit, UT ) {
>> /* do a linear search for Unit in UT.Units (since UT is a UnitTuple)
>> - O(n)*/
>> }
>>
>> template includes( UT1, UT2 ) {
>> /* check for each Unit in UT1 that it is also in UT2 (using contains)
>> - O(n^2) */
>> }
>>
>> template equals( UT1, UT2 ) {
>> immutable bool equals = includes!(UT1,UT2) && includes!(UT2, UT1);
>> }
>> Granted this means that each check takes O(n^2) where n is the number of
>> different units, but it might be worth it - or not. On the small tests
>> I've done it didn't seem to increase compile time significantly, but
>> more research needs to be done. I think that as long as there aren't
>> values with _a lot_ of units (like ten), the extra compile time
>> shouldn't be noticeable. The biggest problem I have with adding IDs is
>> that one will have to manage systems afterwards or have to deal with
>> collisions. Neither one is very nice.
>>
>> - You're right, you don't need dimensions for implicit conversions, of
>> course. And you're also right about possibly making the decision later
>> about implicit conversions. The thing is F#, where units are very
>> popular, only has explicit conversions, and I was trying to steer m
Re: expression templates
Am 28.03.2011 02:19, schrieb Robert Jacques: > Hmm... I don't know you're use case exactly, but it sounds like a case > of operator overload abuse. The design of opCmp was inspired by the > amount of bug prone repetition that happens with C++ style comparison > operators. Furthermore, both opCmp and opEquals have fixed return > types in order to limit abuse. (D also prevents the overload of > certain operators for the same reason). The main reason behind > expression templates is to avoid costly intermediates, but the > expression is always going to be heavier weight than an int, so why > can't you evaluated the expression then and there? If my usage of opCmp is an overload abuse then expression templates are an abuse of D. Maybe this is true, I'm not sure. Clearly opCmp and opEquals were not designed with expression templates in mind. What I would like to achieve is to generate source code from an expression. E.g.: expression: lapl[I,J] = (v[I-1,J] + v[I+1,J] + v[I,J-1] + v[I,J+1]) / h^^2 generated source code: for( j = 0; j < ny; ++j ) for( i = 0; i < nx; ++i ) lap[idx(i,j)] = (v[idx(i-1,j)] + v[idx(i+1,j)] + v[idx(i,j-1)] + v[idx(i,j+1)]) / h^^2; If this is D source code it can be immediately be compiled using mixin(). But it is not necessarily D source code, it could also be OpenCL source code for example. So I'm trying to implement an abstraction layer that enables me to formulate expressions and algorithms independant from the the device they are executed on. A software written on top of this abtraction layer would run on CPU or GPU without any modifications. Of course it is necessary to pass some additional hints about the structure of the expression to the code generator to enable specific optimizations - but I think this can be easily done. The first step to implement such a framework is to parse the expression. I thought expression templates would be the easiest way to do so (as compared to string parsing). Also this automatically ensures that parsing is done at compile time which is necessary for the use of mixin() of course. Although not shown above I definitely need comparison operators for the algorithms I would like to implement (e.g. Godunov type advection schemes for the simulation of compressible fluid flows). Regards, enuhtac
Re: [GSOC idea] enhance regular expressions?
On Mar 29, 11 18:56, bearophile wrote: Dmitry Olshansky: Others (except (?P) and (?P=name) ) also considered common extensions and I planed to add them plus regex comment (#...) where all of ... simply have no effect on matching. Beside the (#...) comments in Python you have also the verbose regex, that allow to put whispace and free #... comments with no parentheses. I find this one of the nicest features, because it allows you to format your regex. Bye, bearophile You can also format regex with r"\d+" // matches the integer part ~ r"(?:\.\d+)?"; // matches the fractional part :)
Re: GCC 4.6
On Mon, 28 Mar 2011 21:54:27 -0400, jasonw wrote: I can't keep wondering if he has Asperger syndrome. I have no tolerance for this. I think the community shares this opinion. Please please, instead of tagging stuff like this, just remove it. Thanks -Steve
Re: i like cakes
On 28/03/2011 10:03, Alix Pexton wrote: try this? Dealing with Internet Trolls - the Cognitive Therapy Approach http://unarmed.shlomifish.org/909.html A... Ha, I saw that article recently, I think it may work for overly excited fanboys, or for people involved in a flame war, but not for trolls. In other words I think it only works for people honest with their intentions (even if very emotional about it), but not with people deliberately spreading confusion, FUD, or just getting a kick out of being a troll. -- Bruno Medeiros - Software Engineer
Re: GSoC-2011 project:: Containers
On Tue, 29 Mar 2011 01:45:02 -0400, Ishan Thilina wrote: I'm glad that you are willing to be a mentor for this project. I'll try my best to come up with a solid project proposal :) I can try to answer your questions, but I have not applied to be an official mentor. Just want to make that clear. My previous message was "I would be a mentor for this, but (reasons why I will not)" Sorry if that is not what you read. -Steve
Re: Is D more complex than C++?
ToNyTeCh wrote: Don wrote: ToNyTeCh wrote: Seriously, I wanna know. How many lines of compiler code does it take for each (Walt should have the best handle on this, surely)? The LOC is one parameter, but I don't want just that -- it just came to mind while typing the overall question. The intricacy of the compiler is much more important thatn the LOC. (Is D's compiler more intricate than C++'s?). Any facts, feelings, guesses, whatever, are all welcomed in response. The complexity in regard to usage would be a good thing to hear about from users of all levels of experience (with D and other languages). This is an interesting question. The difficulty in performing a direct comparison (LOC or similar) is that DMD still has some implementation gaps, so it will get bigger. The parser for D is an order of magnitude simpler than C++, because it is completely separated from the semantic pass. In fact, generally this is true of the language: although there are some features that require a lot of code, they are generally well-contained. Templates are much simpler to implement than in C++, even though they are much more powerful, because they are well-contained. So generally, the compiler is less intricate. But in terms of LOC, by the time everything in D is fully implemented, I doubt that a D compiler will be significantly shorter than a C++ one. And who cares? You were the one who asked the question.
Re: Bruno Medeiros has been accepted as a GSoC 2011 mentor for Digital Mars
On 27/03/2011 19:57, Andrei Alexandrescu wrote: Bruno Medeiros from Google has been accepted as a mentor for the Google Summer of Code 2011 program for Digital Mars. Please join me in congratulating and wishing the best to Bruno. We have three mentors and two pending applications. We are always looking for mentor and student applications. Please refer to this page for how to apply: http://d-programming-language.org/gsoc2011.html Andrei Thanks. I hope to do a good job if indeed any IDE related proposals get accepted. BTW, that page lists me are working for Google, but that is incorrect, not sure what gave you that idea (I wish it were true though :P ) -- Bruno Medeiros - Software Engineer
Re: Using map instead of iteration
bearophile wrote:
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) {}
}
Looks like a bug to me.
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);
}
But the syntax is NOT case a..b, it's case a .. case b.
a..b always has intervals open on the right. There are no exceptions.
Re: [GSoC Proposal] Statically Checked Measurement Units
I am in a slight dilemma, because although I would love to share my work
and ideas with you, right now this would automatically weaken my own
units proposal in comparison to yours. However, as this would be grossly
against the open source spirit, and the point of GSoC certainly can't be
to encourage that, I'll just do it anyway.
Regarding IDs: As I wrote in my previous post, the only point of the
unit IDs in Boost.Units is to provide a strict total order over the set
of units. If you can achieve it without that (see below), you won't need
any artificial numbers which you have to manage.
But why would you need to be able to sort the base units in the first
place? The answer is simple: To define a single type representation for
each possible unit, i.e. to implement type canonicalization. To
illustrate this point, consider the following (pseudocode) example:
auto force = 5.0 * newton;
auto distance = 3.0 * meter;
Quantity!(Newton, Meter) torque = force * distance;
torque = distance * force;
Both of the assignments to »torque« should obviously work, because the
types of »force * distance« and »distance * force« are semantically the
same. In a naïve implementation, however, the actual types would be
different because the pairs of base units and exponents would be
arranged in a different order, so at least one of the assignments would
lead to type mismatch – because a tuple of units is, well, a tuple and
not an (unordered) set.
And this is exactly where the strictly ordered IDs enter the scheme. By
using them to sort the base unit/exponent pairs, you can guarantee that
quantities semantically equivalent always end up with the same
»physical« type.
Luckily, there is no need to require the user to manually assign
sortable, unique IDs to each base type because we can access the mangled
names of types at compile time, which fulfill these requirements. There
are probably other feasible approaches as well, but using them worked
out well for me (you can't rely on .stringof to give unique strings).
When implementing the type sorting code, you might probably run into
some difficulties and/or CTFE bugs, feel free to contact me for related
questions (as I have already wasted enough time on this to get a working
solution…^^).
Regarding strings: I might not have expressed my doubts clearly, but I
didn't assume that your proposed system would use strings as internal
representation at all. What I meant is that I don't see a way how, given
»Quantity!("Widgets/Gadgets")«, to get the Widget and Gadget types in
scope inside Quantity. Incidentally, this is exactly the reason for
which you can't use arbitrary functions/types in the »string lambdas«
from std.algorithm.
David
On 3/28/11 9:43 PM, Cristi Cobzarenco wrote:
- I too was playing around with a units project before GSoC, that is why
I thought doing this project was a good idea. The way I was doing it
without numerical IDs was simply by having more complicated algorithms
for equality, multiplications etc. For example, equality would be
implemented as:
template UnitTuple(P...) {
alias P Units;
}
template contains( Unit, UT ) {
/* do a linear search for Unit in UT.Units (since UT is a UnitTuple)
- O(n)*/
}
template includes( UT1, UT2 ) {
/* check for each Unit in UT1 that it is also in UT2 (using contains)
- O(n^2) */
}
template equals( UT1, UT2 ) {
immutable bool equals = includes!(UT1,UT2) && includes!(UT2, UT1);
}
Granted this means that each check takes O(n^2) where n is the number of
different units, but it might be worth it - or not. On the small tests
I've done it didn't seem to increase compile time significantly, but
more research needs to be done. I think that as long as there aren't
values with _a lot_ of units (like ten), the extra compile time
shouldn't be noticeable. The biggest problem I have with adding IDs is
that one will have to manage systems afterwards or have to deal with
collisions. Neither one is very nice.
- You're right, you don't need dimensions for implicit conversions, of
course. And you're also right about possibly making the decision later
about implicit conversions. The thing is F#, where units are very
popular, only has explicit conversions, and I was trying to steer more
towards that model.
- I seem not to have been to clear about the way I would like to use
strings. The names of the units in the strings have to be the type names
that determine the units. Then one needs a function that would convert a
string like "Meter/Second" to Division!(Meter, Second), I'm not sure how
you would do that in C++. Maybe I'm wrong, but I can't see it.
- I hope it is by now clear that my proposal is not, in fact, string
based at all. The strings are just there to be able to write derived
units in infix notation, something boost solves by using dummy objects
with overloaded operators. The lack of ADL is a problem which I
completely missed; I have immersed myself in C++ completely lately and
I've
Re: Complete D grammar
Rainer Schuetze wrote: > I've extracted the website grammar using some combination of scripts > from the ddoc sources, so if there is interest, I can dig them up... Yep, please make them publicly available so they don't get lost. Though I think we should have an extra official page with the complete grammar in addition to the widespread snippets anyway.
Re: [GSOC idea] enhance regular expressions?
Dmitry Olshansky: > Others (except (?P) and (?P=name) ) also considered common extensions > and I planed to add them plus regex comment (#...) where all of ... simply > have no effect on matching. Beside the (#...) comments in Python you have also the verbose regex, that allow to put whispace and free #... comments with no parentheses. I find this one of the nicest features, because it allows you to format your regex. Bye, bearophile
Re: i like cakes
Am 28.03.2011 03:45, schrieb Gary Whatmore: Hello again I've stayed quiet for a long time because people started accusing me of trolling. But now, I REALLY HATE THIS IDIOT IN REDDIT HE IS DRIVING ME CRAZY. ASSHOLE ASSWIPE SHITHOLE LUNATIC. I HATE HIM. BASHING D JUST BECAUSE HE'S SOME MENTALLY ILL PSYCHOPATE WANTING TO KILL ANDREI AND WALTER :-( THE BEST WE CAN DO IS FIND I LIKE CAKES AND DOWNVOTE ALL HIS VOTES. GO AWAY TROLL! :-( - G.W. Thank god that you're not mentally ill or something. Your post sounds totally sane. Just like having sock-puppets at reddit to downvote D critics is totally sane.
Re: Is D more complex than C++?
On 29 March 2011 11:30, ToNyTeCh wrote: > Francisco Almeida wrote: > > == Quote from ToNyTeCh (t...@nospam.net)'s article > > > >> It doesn't matter to me. I was just posting when I wasn't drunk. > > > > Good for you. It certainly explains a lot. > > fuck you > > > Can we keep the mailing list in a sober tone, please? -- // Yours sincerely // Emil 'Skeen' Madsen
Re: Is D more complex than C++?
Francisco Almeida wrote: > == Quote from ToNyTeCh (t...@nospam.net)'s article > >> It doesn't matter to me. I was just posting when I wasn't drunk. > > Good for you. It certainly explains a lot. fuck you
Re: [GSoC Proposal] Statically Checked Measurement Units
To Don: That is a very good point and I agree that one shouldn't implement features just because they're popular. There don't seem to be many (if any projects) using Boost.Units and only a few that use the feature in F#. But, I think the reason Boost.Units isn't use hasn't got much to do with the idea as much as it does with the implementation. Using units in Boost is very cumbersome. Adding new units (measuring different dimensions) on-the-fly is virtually impossible. I think that that Boost.Units misses the point of units. They should be a natural extension of the type system of a language, not something so limited to the area of natural sciences. D is a new language and we should be pushing the envelope, just because the Boost failed (if it did, it may very well kick-off later) doesn't mean we shouldn't do it. Since it is such a new feature, I think we should talk about its potential rather than its acceptance. When it comes to F#, I think the reason there aren't many projects using units is because there aren't many projects in F# period. It is a very popular feature in the F# community (judging by blog posts and the like) and people are still trying to figure out exactly how to use it. I feel that in F#, it has the potential to become very widely used once people agree on some conventions and good practices. As I said in the abstract, I think the feature fits snugly with other mechanisms in D and seems to be a natural part of a contract-based design, so D programmers should have a predisposition (that C++ programmers might not have) of adopting such a feature. I really hope this doesn't come off as rude; as I said, you make a very good point, one that needs answering. I guess what I'm saying can be summed up as: it is a new feature; there have been mistakes; it has a lot of potential and we can make it better. I'd be curious to hear what you think. To spir: Calling the string representation a small domain specific language is perfect. It is just that, a way of writing arithmetic expressions between types - something we couldn't do inside D grammar. It's much like the lambda definitions in functional. I too am queasy about using strings to represent code, but I think that small DSLs that save effort and improve readability is one place where it's OK. Parsing the expressions at compile time will be fun, thankfully one only needs a stack to do that (Djikstra's shunting yard algorithm) which very is to implement in the functional-style metaprogramming land. To David: Using T.stringof, we can define a total order on types, based on their typenames. I'm still thinking about conversion. To Andrei and Jens: std.datetime won't be simplified _that_ much, but it will probably require some work so that it uses the same unit system as the future units library. I would, of course, take care of this as well. On 29 March 2011 09:06, Don wrote: > Cristi Cobzarenco wrote: > >> First, let me apologize for this very late entry, it's the end of >> university and it's been a very busy period, I hope you will still consider >> it. >> >> Note this email is best read using a fixed font. >> >> PS: I'm really sorry if this is the wrong mailing list to post and I hope >> you'll forgive me if that's the case. >> >> >> === Google Summer of Code Proposal: Statically Checked Units === >> >> >> Abstract >> - >> >> Measurement units allow to statically check the correctness of assignments >> and expressions at virtually no performance cost and very little extra >> effort. When it comes to physics the advantages are obvious – if you try to >> assign a force a variable measuring distance, you've most certainly got a >> formula wrong somewhere along the way. Also, showing a sensor measurement in >> gallons on a litre display that keeps track of the remaining fuel of a plane >> (a big no-no) is easily avoidable with this technique. What this translates >> is that one more of the many hidden assumptions in source code is made >> visible: units naturally complement other contract checking techniques, like >> assertions, invariants and the like. After all the unit that a value is >> measured in is part of the contract. >> > > This is one of those features that gets proposed frequently in multiple > languages. It's a great example for metaprogramming. But, are there examples > of this idea being seriously *used* in production code in ANY language? > (For example, does anybody actually use Boost.Unit?) > -- (Cristi Cobzarenco) Pofile: http://www.google.com/profiles/cristi.cobzarenco
