Re: Functions that return type
On Wednesday, 20 January 2016 at 04:27:27 UTC, blm768 wrote: I guess the constraints are that of a static language. (This is not true.) I'm playing with the design of such a language myself. Basically, anything can create/use/return type objects This is usually possible in dependently typed languages such as Idris, Agda or Coq. Check out Idris, it's rather small but very nice and interesting.
Re: Doubt - Static multidimension arrays
On Tuesday, 19 January 2016 at 20:39:37 UTC, tsbockman wrote: On Tuesday, 19 January 2016 at 19:14:30 UTC, alb wrote: [...] One other thing you may want to keep in mind when working on this kind of thing - when you loop over a multi-dimensional array, the order matters. For large arrays, this: int[c_max][r_max] arr; foreach(r; 0 .. r_max) { foreach(c; 0 .. c_max) { // do something with arr[r][c] here } } Can be *much* faster than this: int[c_max][r_max] arr; foreach(c; 0 .. c_max) { foreach(r; 0 .. r_max) { // do something with arr[r][c] here } } The reason is that the first version access the elements in the order that they are actually stored in memory, whereas the second forces the CPU to jump between rows for each element. [...] You're welcome. And yes, it can definitely be confusing. I understand why the array syntax in D is the way it is, but that still doesn't always save me from mixing things up once in a while anyway. I don't remember where I saw it, but actually, in static multi-dimensional arrays, arr[0][1] is next to arr[0][0] in memory. You can see it with: void main () { ubyte [7][5] arr; import std.stdio : writeln; writeln ( & arr[0][0], " ", & arr[0][1], " ", & arr [1][0] ); }
Re: Mixin Template Function Attributes
On Wednesday, 20 January 2016 at 19:48:04 UTC, jmh530 wrote: On Wednesday, 20 January 2016 at 19:19:04 UTC, Marc Schütz wrote: On Wednesday, 20 January 2016 at 16:37:31 UTC, jmh530 wrote: I'm not sure if this is how the behavior is supposed to be or if it is a bug. I believe, however, that it _is_ a bug that the imported symbols are visible outside the template. Most likely related to the infamous https://issues.dlang.org/show_bug.cgi?id=314 Thanks. The fact that one worked and the other didn't was what I found weird. It looks like this issue covers it https://issues.dlang.org/show_bug.cgi?id=12735 It appears that there is a pull request in the works to fix the behavior.
Re: Mixin Template Function Attributes
On Wednesday, 20 January 2016 at 19:19:04 UTC, Marc Schütz wrote: On Wednesday, 20 January 2016 at 16:37:31 UTC, jmh530 wrote: I'm not sure if this is how the behavior is supposed to be or if it is a bug. I believe, however, that it _is_ a bug that the imported symbols are visible outside the template. Most likely related to the infamous https://issues.dlang.org/show_bug.cgi?id=314 Thanks. The fact that one worked and the other didn't was what I found weird.
Re: Mixin Template Function Attributes
On Wednesday, 20 January 2016 at 16:37:31 UTC, jmh530 wrote: I'm not sure if this is how the behavior is supposed to be or if it is a bug. It's not a bug. The `@attribute:` syntax applies to all following declarations _inside the current scope_, i.e. until your mixin templates closing `}`.
Re: Mixin Template Function Attributes
On Wednesday, 20 January 2016 at 16:37:31 UTC, jmh530 wrote: I'm not sure if this is how the behavior is supposed to be or if it is a bug. I believe, however, that it _is_ a bug that the imported symbols are visible outside the template. Most likely related to the infamous https://issues.dlang.org/show_bug.cgi?id=314
Re: Distribution of D apps
By default, a binary compiled with D will have the standard library statically linked in, so all you need to distribute are other shared libs you choose to use (which might include curl btw if you use the std.net.curl functions). But many .exes from D can be distributed alone and expected to work.
Re: Functions that return type
On Wednesday, 20 January 2016 at 10:04:03 UTC, burjui wrote: That's alright. Parsing and AST construction are trivial with S-expressions (Lisp-like syntax), so if you use them for the early stages of development, you can focus on the type system. When you're done with types, you can switch to making a better grammar for your language. True. I'd been playing with the idea of having multiple syntactic "front-ends" anyway (mainly for the purpose of making DSLs), so it wouldn't be too much of a stretch to use an S-expression syntax. One problem, though, is that I'd either have to extend that syntax to support some of the constructs I want (i.e array literals) or create a bunch of variadic constructor functions (which could be evaluated at compile time). Of course, S-expression syntax is kind of designed to be extensible... That's all off-topic, though. ;)
Re: How to know if opSlice is defined for a type (including built-in types)?
On Wednesday, 20 January 2016 at 15:25:10 UTC, Jonathan M Davis wrote: On Wednesday, January 20, 2016 13:06:00 chardetm via Digitalmars-d-learn wrote: Anyone who has the same problem: I found std.range.primitives.hasSlicing (https://dlang.org/phobos/std_range_primitives.html#hasSlicing) which does exactly what I want! Note that because strings are treated as ranges of dchar regardless of what their actual character type is, arrays of char and wchar (so-called "narrow" strings) are not consider to have slicing or random access by the traits in std.range. So, hasSlicing!string is false, though for anything other than an array of char or wchar, it will do what you're looking for, whereas for arrays of char or wchar, you really shouldn't be using the slice operator on them without knowing that they're what you're operating on so that you take the Unicode issues into account correctly. - Jonathan M Davis Yes and that was the next step of my problem, it turned out that it was already taken into account by hasSlicing! Thank you very much!
Re: Distribution of D apps
On 21/01/16 5:01 AM, Dibyendu Majumdar wrote: Hi, I am trying to understand the options for distributing a D app to users. My assumption is that only the shared libraries and binaries need to be distributed, and I need to include the D libraries. Is this correct? Thanks and Regards Dibyendu Binaries such as such as shared libraries do indeed need to be packaged in the distribution. Static library files do not need to be distributed however.
Mixin Template Function Attributes
I was thinking about using mixin templates to put some module-level default information in a single file so that it doesn't clutter up other files. It works for imports, but it doesn't seem to propagate for function attributes. module_default.d --- module module_default; mixin template module_default() { import std.traits : functionAttributes; import std.stdio : writeln; @safe: } app.d --- import module_default; mixin module_default; int foo(int x) { return x; } void main() { writeln(functionAttributes!foo); } Compiled with dmd app.d module_default.d on Windows 7 64bit. The output is system, when I would expect it to be safe. I'm not sure if this is how the behavior is supposed to be or if it is a bug.
Distribution of D apps
Hi, I am trying to understand the options for distributing a D app to users. My assumption is that only the shared libraries and binaries need to be distributed, and I need to include the D libraries. Is this correct? Thanks and Regards Dibyendu
Re: How to know if opSlice is defined for a type (including built-in types)?
On Wednesday, January 20, 2016 13:06:00 chardetm via Digitalmars-d-learn wrote: > Anyone who has the same problem: I found > std.range.primitives.hasSlicing > (https://dlang.org/phobos/std_range_primitives.html#hasSlicing) > which does exactly what I want! Note that because strings are treated as ranges of dchar regardless of what their actual character type is, arrays of char and wchar (so-called "narrow" strings) are not consider to have slicing or random access by the traits in std.range. So, hasSlicing!string is false, though for anything other than an array of char or wchar, it will do what you're looking for, whereas for arrays of char or wchar, you really shouldn't be using the slice operator on them without knowing that they're what you're operating on so that you take the Unicode issues into account correctly. - Jonathan M Davis
Re: Overload dispatch by templated interface type doesn't seem to work
On Wednesday, 20 January 2016 at 14:01:23 UTC, QAston wrote: To me this suggests that the dispatch by templated interface type Visitor!(RETURN) doesn't work. IMO the order of interfaces shouldn't matter here and the code should simply work. Any ideas? I'm on 2069.2 and when i remove one of the offending classes (Print or Eval) class the other compiles and works.
Overload dispatch by templated interface type doesn't seem to work
Hi, I have the following code: interface Visitable(RETURN) { RETURN accept(Visitor!RETURN); } interface Exp : Visitable!string, Visitable!int { } interface Visitor(RETURN) { RETURN visitLit(Lit e); RETURN visitAdd(Add e); } class Lit : Exp { int val; this(int val) { this.val = val; } override int accept(Visitor!int v) { return v.visitLit(this); } override string accept(Visitor!string v) { return v.visitLit(this); } } class Add : Exp { Exp lhs, rhs; this(Exp lhs, Exp rhs) { this.lhs = lhs; this.rhs = rhs; } override int accept(Visitor!int v) { return v.visitAdd(this); } override string accept(Visitor!string v) { return v.visitAdd(this); } } class Eval : Visitor!int { override int visitLit(Lit e) { return e.val; } override int visitAdd(Add e) { return e.lhs.accept(this) + e.rhs.accept(this); } } class Print : Visitor!string { override string visitLit(Lit e) { return to!string(e.val); } override string visitAdd(Add e) { return "(" ~ e.lhs.accept(this) ~ " + " ~ e.rhs.accept(this) ~ ")"; } } unittest { auto val = new Add(new Lit(1), new Lit(6)).accept(new Eval()); assert(val == 7); auto s = new Add(new Lit(1), new Lit(6)).accept(new Print()); assert(s == "(1 + 6)"); } Which is a dummy AST. It's an example of a visitor pattern. The compiler gives the following error for this code: Error: function Visitable!string.Visitable.accept (Visitor!string) is not callable using argument types (Eval) Error: function Visitable!string.Visitable.accept (Visitor!string) is not callable using argument types (Eval) in Eval.visitAdd. When i swap the order of implemented interfaces in Exp, there's a symmetrical error in Print.visitAdd with Visitor!int. To me this suggests that the dispatch by templated interface type Visitor!(RETURN) doesn't work. IMO the order of interfaces shouldn't matter here and the code should simply work. Any ideas?
Re: Function accepting variadic arguments
On Wednesday, 20 January 2016 at 13:09:13 UTC, Daniel Kozak wrote: On Wednesday, 20 January 2016 at 13:06:14 UTC, pineapple wrote: On Wednesday, 20 January 2016 at 12:56:51 UTC, Ali Çehreli wrote: And there is another example here: http://ddili.org/ders/d.en/templates_more.html#ix_templates_more.tuple%20template%20parameter Ali Thank you! What's the purpose of "is" in the type checks? is is use for compare types Also, how would I utilize isNumeric from std.traits here, in place of checking only for ints? struct S { this(Args...)(Args args) { foreach(Index, Value;args) { if (isNumeric!(Args[index])) { ... } } } } isNumeric!(Args[index] should be: isNumeric!(Args[Index]
Re: Function accepting variadic arguments
On Wednesday, 20 January 2016 at 13:06:14 UTC, pineapple wrote: On Wednesday, 20 January 2016 at 12:56:51 UTC, Ali Çehreli wrote: And there is another example here: http://ddili.org/ders/d.en/templates_more.html#ix_templates_more.tuple%20template%20parameter Ali Thank you! What's the purpose of "is" in the type checks? is is use for compare types Also, how would I utilize isNumeric from std.traits here, in place of checking only for ints? struct S { this(Args...)(Args args) { foreach(Index, Value;args) { if (isNumeric!(Args[index])) { ... } } } }
Re: Function accepting variadic arguments
On Wednesday, 20 January 2016 at 13:04:23 UTC, Daniel Kozak wrote: V Wed, 20 Jan 2016 12:38:20 + pineapple via Digitalmars-d-learn napsáno: import std.stdio; struct S { this(Args...)(Args args) { foreach(Type, Value;args) { writefln("Type: %s value: %s", Args[Type].stringof, Value); } } } void main() { auto s = S(1, "string"); } Type should be named Index :)
Re: Function accepting variadic arguments
On Wednesday, 20 January 2016 at 12:56:51 UTC, Ali Çehreli wrote: And there is another example here: http://ddili.org/ders/d.en/templates_more.html#ix_templates_more.tuple%20template%20parameter Ali Thank you! What's the purpose of "is" in the type checks? Also, how would I utilize isNumeric from std.traits here, in place of checking only for ints?
Re: How to know if opSlice is defined for a type (including built-in types)?
Anyone who has the same problem: I found std.range.primitives.hasSlicing (https://dlang.org/phobos/std_range_primitives.html#hasSlicing) which does exactly what I want!
Re: Function accepting variadic arguments
V Wed, 20 Jan 2016 12:38:20 + pineapple via Digitalmars-d-learn napsáno: > I'd like to make a constructor which takes a variable list of > arguments, of a short list of possible types, with different > handling depending on the type. I haven't been able to find any > documentation or examples that did quite what I'm trying to. Help? > > A fun pseudocode example of what I'm trying to do: > > this(...){ > foreach(argument){ > if(argument is a number){ > do stuff with it; > }else if(argument is of type A){ > do other stuff; > }else if(argument is of type B){ > yet more stuff; > } > } > } > import std.stdio; struct S { this(Args...)(Args args) { foreach(Type, Value;args) { writefln("Type: %s value: %s", Args[Type].stringof, Value); } } } void main() { auto s = S(1, "string"); }
Re: Function accepting variadic arguments
On 01/20/2016 04:38 AM, pineapple wrote: I'd like to make a constructor which takes a variable list of arguments, of a short list of possible types, with different handling depending on the type. I haven't been able to find any documentation or examples that did quite what I'm trying to. Help? A fun pseudocode example of what I'm trying to do: this(...){ foreach(argument){ if(argument is a number){ do stuff with it; }else if(argument is of type A){ do other stuff; }else if(argument is of type B){ yet more stuff; } } } import std.stdio; struct A { double d; } struct B { string s; } struct C { this(T...)(T args) { foreach (arg; args) { static if (is (typeof(arg) == int)) { writefln("int: %s", arg); } else static if (is (typeof(arg) == A) ) { writefln("A: %s", arg); } else static if (is (typeof(arg) == B)) { writefln("B: %s", arg); } } } } void main() { auto c = C(42, A(1.5), B("hello")); } Prints: int: 42 A: A(1.5) B: B("hello") And there is another example here: http://ddili.org/ders/d.en/templates_more.html#ix_templates_more.tuple%20template%20parameter Ali
Function accepting variadic arguments
I'd like to make a constructor which takes a variable list of arguments, of a short list of possible types, with different handling depending on the type. I haven't been able to find any documentation or examples that did quite what I'm trying to. Help? A fun pseudocode example of what I'm trying to do: this(...){ foreach(argument){ if(argument is a number){ do stuff with it; }else if(argument is of type A){ do other stuff; }else if(argument is of type B){ yet more stuff; } } }
Re: How to know if opSlice is defined for a type (including built-in types)?
On Wednesday, 20 January 2016 at 10:44:36 UTC, Rikki Cattermole wrote: template CanSlice(T) { enum CanSlice = __traits(compiles, {T t; auto v = t[0 .. 1];}) || __traits(compiles, {T t; auto v = t.opSlice();}); } Should work. Thanks it works just fine!
Re: How to know if opSlice is defined for a type (including built-in types)?
On 20/01/16 11:41 PM, chardetm wrote: Hi everyone, I was wondering if it was possible to know at compile time if opSlice is defined for a type, including built-in types like "string". Here is the code I have: import std.stdio; struct Test { Test opSlice(size_t i, size_t j) { return this; // We don't care what it returns } } void main () { string s = "Hello"; auto s2 = s[0..2]; static if (is(typeof(&string.opSlice))) writeln("Ok string"); Test t; auto t2 = t[0..2]; static if (is(typeof(&Test.opSlice))) writeln("Ok Test"); } Output: Ok Test How to make it work for "string" too (if possible)? And is there a way to differentiate "opSlice()" from "opSlice(size_t, size_t)" (or "opSlice(T, T)" for any T)? Thank you in advance! template CanSlice(T) { enum CanSlice = __traits(compiles, {T t; auto v = t[0 .. 1];}) || __traits(compiles, {T t; auto v = t.opSlice();}); } Should work.
How to know if opSlice is defined for a type (including built-in types)?
Hi everyone, I was wondering if it was possible to know at compile time if opSlice is defined for a type, including built-in types like "string". Here is the code I have: import std.stdio; struct Test { Test opSlice(size_t i, size_t j) { return this; // We don't care what it returns } } void main () { string s = "Hello"; auto s2 = s[0..2]; static if (is(typeof(&string.opSlice))) writeln("Ok string"); Test t; auto t2 = t[0..2]; static if (is(typeof(&Test.opSlice))) writeln("Ok Test"); } Output: Ok Test How to make it work for "string" too (if possible)? And is there a way to differentiate "opSlice()" from "opSlice(size_t, size_t)" (or "opSlice(T, T)" for any T)? Thank you in advance!
Re: Functions that return type
On Wednesday, 20 January 2016 at 04:27:27 UTC, blm768 wrote: It's not very far along, though. Right now, I have a "compiler" that parses integers and parentheses. ;) That's alright. Parsing and AST construction are trivial with S-expressions (Lisp-like syntax), so if you use them for the early stages of development, you can focus on the type system. When you're done with types, you can switch to making a better grammar for your language.
Re: Partial application of compile time args type deduction
On Wednesday, 20 January 2016 at 00:50:49 UTC, Ali Çehreli wrote: On 01/19/2016 04:22 PM, QAston wrote: [...] Is this it? If so, is it already in std.functional? (I could not find it. :) ) auto appendMapped(alias f, R, T)(R r, T elem) { r ~= f(elem); return r; } int minus(int i) { return -i; } unittest { int[] ar; template bindFirstParam(alias original, alias func, Args...) { auto bindFirstParam(Args...)(Args args) { return original!(func, Args)(args); } } alias appendMinus = bindFirstParam!(appendMapped, minus); assert (appendMinus!(int[], int)(ar, 10) == [-10]); // compiles assert (appendMinus(ar, 10) == [-10]); // doesn't compile } void main() { } Ali Works, thanks!