www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Units of Measurement Library: units-d

reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
I've put David Nadlinger work together with my tweaks on top at

https://github.com/nordlow/units-d

to make it easier to experiment with.

PR are very welcome.
Mar 31 2016
next sibling parent reply ag0aep6g <anonymous example.com> writes:
On 01.04.2016 01:58, Nordlöw wrote:
 https://github.com/nordlow/units-d
From there:
  * Example:
  * ---
  * alias BaseUnit!("Ampere", "A") Ampere;
  * enum ampere = Ampere.init;
  * // or
  * enum ampere = baseUnit!("Ampere", "A");
  * ---
I dislike that the type depends only on the given name. This effectively means that the names are in a global namespace. For example: ---- import experimental.units; struct A { alias BaseUnit!("Ampere", "A") Ampere; enum ampere = Ampere.init; } struct B { alias BaseUnit!("Ampere", "A") Ampere; enum ampere = Ampere.init; } ---- A.Ampere and B.Ampere are the same type here. I think it would be more useful if they weren't. When two unrelated sources define a new unit with the same name, then they shouldn't be compatible. Think of all the different kinds of pounds and miles there used to be in the world. I can't think of a truly nice way to accomplish this, though. As far as I see, it needs a mixin of some kind. Like this, for example: ---- enum string baseUnit = q{ { static struct BaseUnit {/* ... */} return BaseUnit.init; }() }; struct A { enum ampere = mixin(baseUnit); } struct B { enum ampere = mixin(baseUnit); } static assert(!is(typeof(A.ampere) == typeof(B.ampere))); ----
Apr 01 2016
parent reply Simen Kjaeraas <simen.kjaras gmail.com> writes:
On Friday, 1 April 2016 at 19:03:03 UTC, ag0aep6g wrote:
 I dislike that the type depends only on the given name. This 
 effectively means that the names are in a global namespace.
[snip]
 I can't think of a truly nice way to accomplish this, though. 
 As far as I see, it needs a mixin of some kind.
The usual way to fix it would be to include __FILE__ and __LINE__ in the template arguments: // In units/package.d: struct BaseUnit(string name, string symbol = null, string file = __FILE__, size_t line = __LINE__) { // ... } // in foo.d: import experimental.units; struct A { // Actual type is BaseUnit!("Ampere", "A", "foo", 5): alias BaseUnit!("Ampere", "A") Ampere; enum ampere = Ampere.init; } struct B { // Actual type is BaseUnit!("Ampere", "A", "foo", 12): alias BaseUnit!("Ampere", "A") Ampere; enum ampere = Ampere.init; } void main() { assert(!is(B.Ampere == A.Ampere)); } -- Simen
Apr 01 2016
parent reply ag0aep6g <anonymous example.com> writes:
On 01.04.2016 22:59, Simen Kjaeraas wrote:
 The usual way to fix it would be to include __FILE__ and __LINE__ in the
 template arguments:
Right, no mixin this way. I wouldn't call this "truly nice", though. It depends on code formatting to work. Put everything on one line and it breaks. Significant whitespace is a pain when generating code. Though this is not nearly as bad as significant indentation, of course. __FILE__ also kind of breaks separate compilation. All object files have to be compiled from the same directory. Otherwise __FILE__ will be different. __LINE__ has a similar (maybe even more obscure) issue. Add or remove a newline before compiling dependent modules and things break. Usually, one recompiles all dependents when a dependency changes, but a significant newline, really?
Apr 01 2016
parent reply Simen Kjaeraas <simen.kjaras gmail.com> writes:
On Friday, 1 April 2016 at 21:46:35 UTC, ag0aep6g wrote:
 On 01.04.2016 22:59, Simen Kjaeraas wrote:
 The usual way to fix it would be to include __FILE__ and 
 __LINE__ in the
 template arguments:
Right, no mixin this way. I wouldn't call this "truly nice", though. It depends on code formatting to work. Put everything on one line and it breaks. Significant whitespace is a pain when generating code. Though this is not nearly as bad as significant indentation, of course. __FILE__ also kind of breaks separate compilation. All object files have to be compiled from the same directory. Otherwise __FILE__ will be different. __LINE__ has a similar (maybe even more obscure) issue. Add or remove a newline before compiling dependent modules and things break. Usually, one recompiles all dependents when a dependency changes, but a significant newline, really?
I kinda agree. And looking at https://dlang.org/spec/traits.html, I see there's __MODULE__, which would probably be a better choice than __FILE__. As for __LINE__, what we'd want is basically something like __CONTEXT__, which doesn't exist, but might be the .mangleof of the surrounding scope: struct S(string ctx = __CONTEXT__) { pragma(msg, ctx); } S!() a; // "3foo" void bar() { S!() b; // "_D3foo3barFZv" } struct S2 { S!() c; // "S3foo2S2" void baz() { S!() d; // "_D3foo2S23bazMFZv" } } That'd remove the problem of significant whitespace. In fact, it'd also eliminate the need for __MODULE__ in this case. Still though, that's not enough if we want this to work: void foo() { alias a = Foo!(); alias b = Foo!(); assert(!isSame!(a, b)); } We could also add __COLUMN__, which would be the horizontal index of the instantiation's beginning: foo(3, Bar!3.baz); // ^Here. Position 11. Next problem: void main() { pragma(msg, __LINE__); mixin("pragma(msg, __LINE__);\npragma(msg, __LINE__);"); pragma(msg, __LINE__); } That prints '4' twice - once for the actual line 4, the other for the second line of the mixin. However, __FILE__ is different, so I guess __CONTEXT__ could also be. -- Simen
Apr 01 2016
next sibling parent reply Meta <jared771 gmail.com> writes:
On Friday, 1 April 2016 at 22:54:53 UTC, Simen Kjaeraas wrote:
 On Friday, 1 April 2016 at 21:46:35 UTC, ag0aep6g wrote:
 On 01.04.2016 22:59, Simen Kjaeraas wrote:
 The usual way to fix it would be to include __FILE__ and 
 __LINE__ in the
 template arguments:
Right, no mixin this way. I wouldn't call this "truly nice", though. It depends on code formatting to work. Put everything on one line and it breaks. Significant whitespace is a pain when generating code. Though this is not nearly as bad as significant indentation, of course. __FILE__ also kind of breaks separate compilation. All object files have to be compiled from the same directory. Otherwise __FILE__ will be different. __LINE__ has a similar (maybe even more obscure) issue. Add or remove a newline before compiling dependent modules and things break. Usually, one recompiles all dependents when a dependency changes, but a significant newline, really?
I kinda agree. And looking at https://dlang.org/spec/traits.html, I see there's __MODULE__, which would probably be a better choice than __FILE__. As for __LINE__, what we'd want is basically something like __CONTEXT__, which doesn't exist, but might be the .mangleof of the surrounding scope: struct S(string ctx = __CONTEXT__) { pragma(msg, ctx); } S!() a; // "3foo" void bar() { S!() b; // "_D3foo3barFZv" } struct S2 { S!() c; // "S3foo2S2" void baz() { S!() d; // "_D3foo2S23bazMFZv" } } That'd remove the problem of significant whitespace. In fact, it'd also eliminate the need for __MODULE__ in this case. Still though, that's not enough if we want this to work: void foo() { alias a = Foo!(); alias b = Foo!(); assert(!isSame!(a, b)); } We could also add __COLUMN__, which would be the horizontal index of the instantiation's beginning: foo(3, Bar!3.baz); // ^Here. Position 11. Next problem: void main() { pragma(msg, __LINE__); mixin("pragma(msg, __LINE__);\npragma(msg, __LINE__);"); pragma(msg, __LINE__); } That prints '4' twice - once for the actual line 4, the other for the second line of the mixin. However, __FILE__ is different, so I guess __CONTEXT__ could also be. -- Simen
What is needed is Lisp's gensym construct.
Apr 01 2016
parent Simen Kjaeraas <simen.kjaras gmail.com> writes:
On Saturday, 2 April 2016 at 01:19:45 UTC, Meta wrote:
 What is needed is Lisp's gensym construct.
That's basically what I said, no? :p One problem of lisp's gensym (if we were to use it in D) is that it's simply a monotonically increasing number with a global prefix. It's perfect for the language it's in, and all but useless in D. For this very reason, I have made a stab at implementing __GENSYM__ in D. It follows basically the ideas I outlined above, counter for the given mangled name: module bar; struct Ham(string gensym = __GENSYM__) { pragma(msg, gensym); } struct Eggs(string gensym = __GENSYM__) { pragma(msg, gensym); } // =========================== module foo; import bar; pragma(msg, __GENSYM__); // 3foo_1 void main() { pragma(msg, __GENSYM__); // _Dmain_1 Ham!() a; // _Dmain_3bar_1 Ham!() b; // _Dmain_3bar_2 assert(!is(typeof(a) == typeof(b))); Eggs!() c; // _Dmain_3bar_3 S2!() d; // _Dmain_3foo_1 } struct Qux { pragma(msg, __GENSYM__); // 3foo3Qux_1 void baz() { pragma(msg, __GENSYM__); // _D3foo3Qux3bazMFZv_1 Ham!() a; // _D3foo3Qux3bazMFZv_3bar_1 } } struct S2(string gensym = __GENSYM__) { pragma(msg, gensym); } Should I file an enhancement for this? -- Simen
Apr 04 2016
prev sibling parent crimaniak <crimaniak gmail.com> writes:
On Friday, 1 April 2016 at 22:54:53 UTC, Simen Kjaeraas wrote:

...
 I kinda agree. And looking at 
 https://dlang.org/spec/traits.html, I see there's __MODULE__, 
 which would probably be a better choice than __FILE__.
I think adding something like __UNIQUE_NAME__ to predefined constants will allow to avoid all these perversions. The only thing to think here about uniqueness scope.
Apr 02 2016
prev sibling parent Jack Stouffer <jack jackstouffer.com> writes:
On Thursday, 31 March 2016 at 23:58:54 UTC, Nordlöw wrote:
 I've put David Nadlinger work together with my tweaks on top at

 https://github.com/nordlow/units-d

 to make it easier to experiment with.

 PR are very welcome.
Nice work. I have yet to play around with it, but this is definitely going to need pre-made symbols for the United States customary system like SI has before it goes into Phobos.
Apr 01 2016