Re: When compiling multiple source files
On 2013-08-20 00:27, ProgrammingGhost wrote: Is it possible that if I just try to compile 1 file it could imports enough libraries that import/need the definitions for additional large libraries which in turn also imports everything causing ram issues? I'm sure in practice this will almost never happen. But I don't doubt there are main libraries that use other large libraries and everything imports/uses everything I guess I should add that we do have some problems with RAM running the unit tests in Phobos (the standard library). But this is rather due to the heavy use of templates and other compile time features. Not because there is too much code/text in the files. -- /Jacob Carlborg
Re: When compiling multiple source files
On 2013-08-20 00:27, ProgrammingGhost wrote: Is it possible that if I just try to compile 1 file it could imports enough libraries that import/need the definitions for additional large libraries which in turn also imports everything causing ram issues? I'm sure in practice this will almost never happen. But I don't doubt there are main libraries that use other large libraries and everything imports/uses everything It's theoretically possible. But one big difference between D and C/C++, is that D uses symbolic inclusion where C/C++ uses textual inclusion. In C/C++ you end up with these enormous translation units due to this. This won't happen in D. In C/C++ when you see "include ", for example, the preprocessor will basically copy-paste the content of stdio.h to where the include was located. In D the compiler just makes a note that a given file includes another, no content is copied. -- /Jacob Carlborg
Re: A Discussion of Tuple Syntax
On 08/20/2013 02:18 AM, Andrei Alexandrescu wrote:
Why would it be necessary to return an object of type TypeTuple (i.e.
template tuple)?
- Elegance. Eg:
auto seq(T...)(T arg){ return arg; }
auto fold(alias a,S,R)(S start, R range){ ... }
seq(0,[1,2,3]).fold!((a,b)=>a+b);
(Obviously you can get close by requiring expansion at the call site.)
- ABI
Multiple return values could use a more efficient ABI than struct
instances because they do not have an address.
- Consistency
A type whose instances cannot be returned from a function is just weird
language design.
It has no state.
It may alias variables that do.
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 21:03:50 UTC, Andrei Alexandrescu wrote: I'm saying that there's a mix of useful stuff and just syntactic additions that are arguably less so. In my opinion: a) destructuring tuples in auto declarations - good to have: auto (a, b, c) = functionReturningTupleOrStaticArrayWith3Elements(); I propose the following rewrite : auto tmp = functionReturningTupleOrStaticArrayWith3Elements(); assert(tmp.length == 3); auto a = tmp[0]; auto b = tmp[1]; auto c = tmp[2]; That way any type user can take advantage of the new syntax, and it is easy to implement as it is simple rewrite rules. Note that tmp do not need to be an lvalue to avoid uneeded copies. I'd also like to see the term Tuple for variadic template parameter go away. This is confusing the hell out of everybody, as the current conversation is showing.
Re: A Discussion of Tuple Syntax
On Monday, August 19, 2013 13:45:33 Andrei Alexandrescu wrote: > but once the bikeshed is up for painting, the > rainbow won't suffice. LOL! I'm going to have to remember that one. - Jonathan M Davis
Re: std.serialization: pre-voting review / discussion
On Monday, 19 August 2013 at 18:06:00 UTC, Johannes Pfau wrote:
Am Mon, 19 Aug 2013 16:21:44 +0200
schrieb "Tyler Jameson Little" :
On Monday, 19 August 2013 at 13:31:27 UTC, Jacob Carlborg
wrote:
> On 2013-08-19 15:03, Dicebot wrote:
>
>> Great! Are there any difficulties with the input?
>
> It just that I don't clearly know how the code will need to
> look like, and I'm not particular familiar with implementing
> range based code.
Maybe we need some kind of doc explaining the idiomatic usage
of ranges?
Personally, I'd like to do something like this:
auto archive = new XmlArchive!(char); // create an XML
archive
auto serializer = new Serializer(archive); // create the
serializer
serializer.serialize(foo);
pipe(archive.out, someFile);
Your "pipe" function is the same as
std.algorithm.copy(InputRange,
OutputRange) or std.range.put(OutputRange, InputRange);
Right, for some reason I couldn't find it... Moot point though.
An important question regarding ranges for std.serialization is
whether
we want it to work as an InputRange or if it should _take_ an
OutputRange. So the question is
-
auto archive = new Archive();
Serializer(archive).serialize(object);
//Archive takes OutputRange, writes to it
archive.writeTo(OutputRange);
vs
auto archive = new Archive()
Serializer(archive).serialize(object);
//Archive implements InputRange for ubyte[]
foreach(ubyte[] data; archive) {}
-
I'd use the first approach as it should be simpler to
implement. The
second approach would be useful if the ubyte[] elements were
processed
via other ranges (map, take, ...). But as binary data is usually
not processed in this way but just stored to disk or sent over
network
(basically streaming operations) the first approach should be
fine.
+1 for the first way.
The first approach has the additional benefit that we can
easily do
streaming like this:
auto archive = new Archive(OutputRange);
//Immediately write the data to the output range
Serializer(archive).serialize([1,2,3]);
This can make a nice one-liner for the general case:
Serializer(new Archive(OutputRange)).serialize(...);
Another point is that "serialize" in the above example could be
renamed to "put". This way Serializer would itself be an
OutputRange
which allows stuff like
[1,2,3,4,5].stride(2).take(2).copy(archive);
Then serialize could also accept InputRanges to allow this:
archive.serialize([1,2,3,4,5].stride(2).take(2));
However, this use case is already covered by using copy so it
would just
be for convenience.
This is nice, but I think I like serialize() better. I also don't
think serializing a range is it's primary purpose, so it doesn't
make a lot of sense to optimize for the uncommon case.
Re: A Discussion of Tuple Syntax
Sorry I cannot reply to each thread comments quickly, so I discharge my
opinions at once.
D's built-in tuple can contain following entities:
- Type
int, long, array types, AA types, user-defined types, etc
- Expressions
interger, string literal, etc
- Symbol
user-defined types, templates, template instances, etc
Note that: an user-defined type would be treated as both Type and Symbol.
template Test() {}
alias X = std.typetuple.TypeTuple!(
int, long, char[], int[int], const Object, // Types
1, "str", [1,2,3], // Expressions (literal values)
object.Object, Test, Test!(), // Symbols
);
If all of the elements in a built-in tuple are Type, today it is normally
called "Type Tuple".
If all of the elements in a built-in tuple are Expressions, today it is
normally called "Expression Tuple".
Note that: today we cannot create a built-in tuple without using
TemplateTupleParameter.
TemplateTupleParameter cannot take expressions non-literal expressions,
therefore
most of current built-in tuples would contains only literal values as the
Expressions.
std.typecons.Tuple is an artifact of built-in tuple + alias this.
struct Tuple(T...) {
T expand; // 'expand' is a built-in tuple of
// the implicitly defined fields that
// typed T[0], T[1], ... T[$-1].
// In spec, this is called "TupleDeclaration".
alias expand this; // forward indexing/slicing operators to
// the TupleDeclaration 'expand'
}
Tuple!(int, string) t;
t[];// t.expand[]
t[0..$];// t.expand[0..$]
t[1]; // t.expand[1]
So, std.typecons.Tuple _is not special_. You can define another Tuple
struct in the same way.
We should not define new syntax for the library utility std.typecons.Tuple.
If you want to return multiple values from a function, you must always wrap
them by std.typecons.Tuple, or other used-defined types. You cannot
directly return built-in tuple from a function.
(Built-in tuple return is mostly equivalent with multiple-value-return
issue. However it would be mostly impossible that defining calling
conversion scheme for that in portable)
The combination of built-in tuple and alias this would be one of the case
of built-in tuple of non-literal Expressions.
For example, `t.expand[1]` is equivalent with the dot expression
`t.__field_1` which cannot be taken by TemplateTupleParameter.
Therefore, `t.expand` would be the built-in tuple of the two dot
expressions `t.__field_0` and `t.__field_1`.
Therefore, calling built-in tuple "Alias Tuple" would not be correct so
built-in tuple can contain expressions that cannot be aliased.
My opinions agains various syntax proposals:
#(1, "str")
--> The character '#' is already used for the start of "Special Token
Sequences"
http://dlang.org/lex.html#Special Token Sequence
It is recognized in lexing phase, so adding semantic meaning to the '#'
character would be a contradict of D's principle.
Quote from http://dlang.org/lex.html
"The lexical analysis is independent of the syntax parsing and the semantic
analysis."
Kenji Hara
Re: A Discussion of Tuple Syntax
2013/8/20 H. S. Teoh > Actually, reading through DIP32 again, it sounds like Kenji is proposing > the *same* syntax for both built-in tuples and std.typecons.Tuple. In > the code example under "Generic type/expression tuple syntax", he refers > to them respectively as "tuple type" and "tuple value". Mixing is also > allowed (e.g., in the "alias Fields" line). > Honestly, I had intended DIP32 to provide *uniform* syntax for both built-in tuple and std.typecons.Tuple. However, finally, I noticed that would be _impossible_. I'll withdraw DIP32 and will open new DIP for only built-in tuple syntax proposal. Kenji Hara
Re: A Discussion of Tuple Syntax
Aggh, misposted. Let's try that again.
On Tuesday, 20 August 2013 at 02:51:20 UTC, Meta wrote:
On Tuesday, 20 August 2013 at 01:06:28 UTC, H. S. Teoh wrote:
Actually, reading through DIP32 again, it sounds like Kenji is
proposing
the *same* syntax for both built-in tuples and
std.typecons.Tuple. In
the code example under "Generic type/expression tuple syntax",
he refers
to them respectively as "tuple type" and "tuple value". Mixing
is also
allowed (e.g., in the "alias Fields" line).
Maybe mixing should be disallowed, then, unless your tuple was
constructed from a variadic template argument list.
//Error. Tuple containing types
//at runtime doesn't make any sense
auto tup = #(1, int);
//Error
auto tup = #(int, string);
//Ok
auto tup = #(1, "a", true);
T[0] Test(T...)(T ts)
{
//Okay, each element of T can
//be statically inspected to ensure
//that you don't do something weird
auto tup = T;
//Also okay
alias tup = T;
//Error
auto tup = #(int, string, bool);
//Ok
alias tup = #(int, string, bool);
}
There might be some areas where this conflation may cause
trouble,
...
Actually, looking at this again, it seems the problem is with
the "tup = {1; x}" line. Does {1; x} in the above code mean
{1; 123}, or does it mean {1; {alias of x}}? For example, if
you wrote this:
int x=123;
auto tup = {1; x};
x++;
writeln(tup);
What should be the output?
I'd say that x++ would not modify the x within the tuple. It's
the same as:
int x = 123;
auto y = x;
x++;
writeln(y);
Y is not changed, of course. However, if the tuple contains a
reference type, such as a slice, then it would be modified.
int[] x = [123];
auto tup = #(1, x);
x[]++;
//Prints #(1, [124])
writeln(tupe);
Should the output change if the second line
is changed to:
alias tup = {1; x};
?
I don't think this should be possible. It would be the same as
doing:
alias two = 3; //Error
Unless the tuple contained only types. Then it would be possible.
alias intAndStr = #(int, string); //Ok
The semantics are fairly easy when a tuple contains only values
and only types. The hard part is when it contains both values AND
types, so that should be severely limited, maybe only within
variadic templates.
I can't remember where this was mentioned... I think it was in
one of the other tuple threads I linked, and I think you brought
it up, Teo.
auto tup = #(1, "a");
alias tupType = typeof(tup);
While tup is a value, its type is #(int, string). In other words,
the type of a tuple value is a TypeTuple (alias tuple, whatever).
Which means the type of a tuple is a tuple itself, which is
pretty nifty.
Re: A Discussion of Tuple Syntax
On Tuesday, 20 August 2013 at 01:06:28 UTC, H. S. Teoh wrote:
Actually, reading through DIP32 again, it sounds like Kenji is
proposing
the *same* syntax for both built-in tuples and
std.typecons.Tuple. In
the code example under "Generic type/expression tuple syntax",
he refers
to them respectively as "tuple type" and "tuple value". Mixing
is also
allowed (e.g., in the "alias Fields" line).
Maybe mixing should be disallowed, then, unless your tuple was
constructed from a variadic template argument list.
auto tup = #(1, int); //ERROR
template TMP(T...)
{
auto tup = T;
}
So it sounds like this is similar to what bearophile was
suggesting --
the unification of built-in tuples and Phobos Tuples. I suppose
the
intention is that if a built-in tuple like (1, "a", 1.0) is
used as a
value, it would be automatically translated into a runtime
tuple value.
I'm not sure if the reverse is possible, though, since if the
tuple
contains some runtime values, then it's not possible to
translate it
back into a built-in tuple.
Actually, going in either direction requires some restrictions;
for
example, if a tuple contains a type, like (1, int), then it's
impossible
to translate it into a runtime tuple (types have no runtime
value in and
of themselves). Similarly, if a tuple contains a runtime
variable, then
it's impossible to use it as a compile-time tuple. But if a
tuple
contains only compile-time known values, then it's in theory
usable both
as a built-in tuple and a runtime tuple.
There might be some areas where this conflation may cause
trouble,
though; for example, if you have a tuple (1, x) where x is a
runtime
variable, then should it be treated as (1, {alias of x}) or (1,
{runtime
value of x})? The former would happen if you pass it to a
template that
expects an int and and alias parameter, for example, and the
latter if
you try to store this tuple into a variable. It may lead to
this weird
situation:
template Tmpl(int x, alias y) { ... }
int x=123;
auto tup = {1; x};
alias T = Tmpl!tup; // OK, 1 -> int x, x -> alias y
auto tup2 = tup;// store {1;123} into variable
alias U = Tmpl!tup2; // ERROR: cannot instantiate template
with runtime variable
Actually, looking at this again, it seems the problem is with
the "tup =
{1; x}" line. Does {1; x} in the above code mean {1; 123}, or
does it
mean {1; {alias of x}}? For example, if you wrote this:
int x=123;
auto tup = {1; x};
x++;
writeln(tup);
What should be the output? Should the output change if the
second line
is changed to:
alias tup = {1; x};
?
T
Re: OT; Will MS kill .NET ?
BTW, I was disappointed to find out (and I had to dig through several contradictory articles to clarify that) that WinRT is not planned to (eventually) be the new core Windows API (the lowest level one, ignoring the NT "native" API) , upon which higher level APIs (like .Net) are built. Things (like WinRT itself) are going to still be built upon Win32/64, with all the cruft, and WinRT is just a side alternative -- a facade to the old crufty API and all its compatibility issues, not something authoritative. For instance, windows paths will still have the old Win32 limits, even if the NT API (and WinRT) is less restrictive.
Re: new operator chaining (D vs Java)
On Tuesday, 20 August 2013 at 02:20:27 UTC, Andrej Mitrovic wrote: This syntax will work in the next release (2.064). Wow, now that is a coincidence! :-) (how it took me so long to notice it, just before it was going to be added to the language)
Re: OT; Will MS kill .NET ?
I thought that, if anything, Microsoft was regretting going too high-level. There is a video from Channel 9 with Herb Sutter (perhaps [1], not sure) where I recall him saying that the .Net mania had died out and Microsoft developers were again focusing on C++. [1] http://channel9.msdn.com/posts/C-and-Beyond-2011-Herb-Sutter-Why-C
Re: new operator chaining (D vs Java)
On Tuesday, 20 August 2013 at 02:11:41 UTC, Luís Marques wrote: Is there any particular (purposeful) reason why D cannot directly chain calls after new? (a quick Google search did not help). This syntax will work in the next release (2.064).
new operator chaining (D vs Java)
I've used D to some extent since around 2004, but I don't recall noticing this before (although I wouldn't trust 9 year old memories!): D: (new Class()).foo(); Java: new Class().foo(); Is there any particular (purposeful) reason why D cannot directly chain calls after new? (a quick Google search did not help).
Re: OT; Will MS kill .NET ?
On Mon, 19 Aug 2013 18:28:37 -0700, Nick B wrote: Hi. I can across this off-topic. It is 2 years old, but it seems well written. http://i-programmer.info/professional-programmer/i-programmer/2591-dumping-net-microsofts-madness.html Here is a preview book from MS, to back up this point above: http://blogs.msdn.com/b/microsoft_press/archive/2012/08/20/free-ebook-programming-windows-8-apps-with-html-css-and-javascript-second-preview.aspx Has anyone heard anything more up to date ? Will MS just let .NET slowly die ? Nick They'd LOVE to, but they can't, it's just to entrenched on the server. They're working on replacing it slowly with node.js and the like, but it'll be a LONG time before server devs are willing to use it for mission critical stuff, if they ever are. More likely, it'll end up like Java, pay VERY close attention to moves that Miguel de Icaza makes very carefully, nobody is better positioned to take up the .NET flag than him and his crew at Xamarin. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: A Discussion of Tuple Syntax
Andrei Alexandrescu: return tuple(1, "a"); About the same syntax should work for both packing and unpacking tuples. Bye, bearophile
Re: A Discussion of Tuple Syntax
Random idea - what do you thing about merging current Tuple and TypeTuple into one and than separating them back with new and clear semantics - "run-time tuple" vs "compile-time tuple" with two distinct literals? TypeTuple and Tuple then can remain as compatibility deprecated implementations.
Re: Possible solution to template bloat problem?
On Tue, Aug 20, 2013 at 02:48:27AM +0200, Dicebot wrote: > On Tuesday, 20 August 2013 at 00:34:38 UTC, Ramon wrote: > >Well, I'm afraid that's what templates are. One (or the compiler) > >fills them in and that's it. > > > >In other words: Templates are compile time while (real) generics > >are run time. This basically comes down to have some way of > >designating classes as, for instance, comparable and then either > >running along the object chain comparing all built in objects > >(with built in compare functionality) or having a compare > >implemented (Of course, there is also arithmetic functions, etc.). In that case, the "generics" you're talking about amounts basically to OO polymorphism. You have the same machine code that can process diverse types by using indirection to abstract away the implementation details. This is no doubt useful, as OO itself proves, but it does come with a cost: using indirection incurs a (small, but nevertheless non-zero) performance hit. Inside inner loops, this can be a performance killer. At the machine code level, it's actually not possible to use the same code for, e.g., comparing two ints vs. comparing two floats. You need different machine instructions for them, so there is no single piece of code that can be reused for both types. You have to somehow switch between them at runtime depending on what types are being passed in. (It gets even hairier if you're comparing, say, ints and floats, in which case additional instructions must be used for promoting one type to another so that they are comparable.) So, say you call your function "less". In order to actually run, you need one version for comparing ints, another for comparing floats, etc.. This is what templates do. Alternatively, you use indirection: int and float can be associated with some static data structure that describes each type, say it has a function pointer that, for ints, point to the function that compares int, and for floats, point to the function that compares floats. Then the caller doesn't actually directly call the low-level int/float-specific functions, but they always look up the function pointer. This is, in essence, how OO polymorphism works: each class has a vtable with function pointers to the specific implementation of each overloaded method. Then at runtime, you call whatever function the vtable points to, thus achieving runtime genericity. The problem with indirection is that it's expensive: given two objects to be compared, you need to dereference the pointer to those objects, then dereference the pointer to their respective vtables, then dereference the function pointer in the vtables in order to call the function. Templates, OTOH, are compile-time bound: the compiler ascertains at compile-time that your particular piece of code is comparing two ints, so it bypasses all of the expensive runtime dereferencing, and directly calls the function for comparing ints. The resulting code is inflexible, in the sense that you can't change, at runtime, the arguments to floats -- it would fail horribly -- but it avoids 3 pointer dereferences. When inside an inner loop, this can mean the difference between smooth animation and unusably jerky animation. The cost, of course, is that if you need the same piece of code for comparing both ints and floats, then the compiler has to generate two copies of the code, one to handle ints, and the other to handle floats. The saving grace, as Dicebot points out, is that if these copies of code are small enough, they will be inlined, so you can even save on the cost of a function call. This somewhat reduces the resulting code size -- you save on function call instructions and stack push/pops, etc., but you're still paying for the duplicated code. This is the current state of the art. Now, my dream is that one day, perhaps compilers will get smart enough that you don't even need to worry about the distinction between templates and runtime polymorphism anymore -- you specify what you want to get done, and the compiler determines, based on characteristics of the target machine and how the program as a whole will use that particular piece of code, whether to use indirection or template expansion. Or maybe even a mix of both, depending on the situation. [...] > Reminds me: how hard is writing own linker is again? :) Honestly, I think it's about time linker technology is rethought and developed further. Possible developements are automatic elision of unused code sections (already implemented in some linkers), automatic merging of identical sections (not sure if implemented yet -- may require language support), link-time inlining, reordering of symbols to increase code locality during execution (optimize for CPU caches), etc.. Or more ambitiously, better integration with compiler so that the linker has access to compile-time structures to help it make decisions about optimization. Present-day object file formats are too far along the process to their execut
Re: Ideas for a brand new widget toolkit
On 8/19/2013 5:01 PM, Ramon wrote: > I suggest to first find out what we really want (and therefore who "we" > is). ... > My first target would be something like "designing a new 'fox' fully > using D's superior capabilities and doing that along the lines I listed > above". > > In other words: Let's scratch some itching that is a) common and b) not > yet properly addressed by what is available. IMO, a useful start would be choosing a moderately real-life use case and stepping through imaginary code or markup that would be required for it to work using each proposed approach (including data binding, event handling and so on).
OT; Will MS kill .NET ?
Hi. I can across this off-topic. It is 2 years old, but it seems well written. http://i-programmer.info/professional-programmer/i-programmer/2591-dumping-net-microsofts-madness.html Here is a preview book from MS, to back up this point above: http://blogs.msdn.com/b/microsoft_press/archive/2012/08/20/free-ebook-programming-windows-8-apps-with-html-css-and-javascript-second-preview.aspx Has anyone heard anything more up to date ? Will MS just let .NET slowly die ? Nick
Re: A Discussion of Tuple Syntax
On Tue, Aug 20, 2013 at 02:40:00AM +0200, Meta wrote:
> On Tuesday, 20 August 2013 at 00:29:17 UTC, H. S. Teoh wrote:
> >Sounds like you're confused about what built-in tuples are (and
> >you wouldn't be the first -- they're rather confusing things).
>
> I know the difference between std.typecons.Tuple and the built-in
> tuples. What I'm confused about is I thought that the main objective
> of the tuple literal syntax (destructuring/pattern matching aside)
> was a means to have first-class tuples. That is, tuples that have
> their own literal syntax, have a list of valid operations that can
> be done on them, can be passed to functions, and can be returned
> from functions.
Actually, reading through DIP32 again, it sounds like Kenji is proposing
the *same* syntax for both built-in tuples and std.typecons.Tuple. In
the code example under "Generic type/expression tuple syntax", he refers
to them respectively as "tuple type" and "tuple value". Mixing is also
allowed (e.g., in the "alias Fields" line).
So it sounds like this is similar to what bearophile was suggesting --
the unification of built-in tuples and Phobos Tuples. I suppose the
intention is that if a built-in tuple like (1, "a", 1.0) is used as a
value, it would be automatically translated into a runtime tuple value.
I'm not sure if the reverse is possible, though, since if the tuple
contains some runtime values, then it's not possible to translate it
back into a built-in tuple.
Actually, going in either direction requires some restrictions; for
example, if a tuple contains a type, like (1, int), then it's impossible
to translate it into a runtime tuple (types have no runtime value in and
of themselves). Similarly, if a tuple contains a runtime variable, then
it's impossible to use it as a compile-time tuple. But if a tuple
contains only compile-time known values, then it's in theory usable both
as a built-in tuple and a runtime tuple.
There might be some areas where this conflation may cause trouble,
though; for example, if you have a tuple (1, x) where x is a runtime
variable, then should it be treated as (1, {alias of x}) or (1, {runtime
value of x})? The former would happen if you pass it to a template that
expects an int and and alias parameter, for example, and the latter if
you try to store this tuple into a variable. It may lead to this weird
situation:
template Tmpl(int x, alias y) { ... }
int x=123;
auto tup = {1; x};
alias T = Tmpl!tup; // OK, 1 -> int x, x -> alias y
auto tup2 = tup;// store {1;123} into variable
alias U = Tmpl!tup2;// ERROR: cannot instantiate template with
runtime variable
Actually, looking at this again, it seems the problem is with the "tup =
{1; x}" line. Does {1; x} in the above code mean {1; 123}, or does it
mean {1; {alias of x}}? For example, if you wrote this:
int x=123;
auto tup = {1; x};
x++;
writeln(tup);
What should be the output? Should the output change if the second line
is changed to:
alias tup = {1; x};
?
T
--
A mathematician is a device for turning coffee into theorems. -- P. Erdos
Re: Possible solution to template bloat problem?
On Tuesday, 20 August 2013 at 00:34:38 UTC, Ramon wrote:
Well, I'm afraid that's what templates are. One (or the
compiler) fills them in and that's it.
In other words: Templates are compile time while (real)
generics are run time. This basically comes down to have some
way of designating classes as, for instance, comparable and
then either running along the object chain comparing all built
in objects (with built in compare functionality) or having a
compare implemented (Of course, there is also arithmetic
functions, etc.).
While this sounds great it actually carries some code weight
("bloat") with it, too because all that functionality must be
somewhere. It gets (relatively) cheaper though when being
heavily used.
What you speak is true for languages with "generics" where amount
of generated code is pretty much equal to one that would have
been written by hand. But in D templates do much more and there
is no practical reasons other one quality of implementation to
keep it that way.
For example, template constraints and stuff used during CTFE are
low-hanging fruits. Those don't need to be emitted in resulting
executable at all being only used at compile time.
More theoretically complex problem is stuff like std.algorithm -
simply using something like map will result in several hundreds
(!) of trivial template instances most of which will be inlined
and never actually used in resulting binary. That is something
that link-stage gargabe collection can take care of with a
totally awesome results. I doubt it can be done by compiler
itself but maybe there are some options I have missed.
In a perfect world using templates implies generic algorithms not
generic code generation. it same thing as manual assembly - with
modern optimizers and inlining capabilities all this crap must be
boiled down to same code as carefully crafted manual one. No
reasons to not do it.
Reminds me: how hard is writing own linker is again? :)
Re: std.serialization: pre-voting review / discussion
Seems like your memory has indeed faded a bit. ;) Versioning is an integral idea of formats like Protobuf and Thrift. For example, see the "A bit of history" section right on the doc overview page. [1] You might also want to read through the (rather dated) Thrift whitepaper to get an idea about what the design constraints for it were. [2] The main point is that when you have deployed services at the scale Google or Facebook work with, you can't just upgrade all involved parties simultaneously on a schema change. So, having to support multiple versions running along each other is pretty much a given, and the best way to deal with that is to build it right into your protocols. David [1] https://developers.google.com/protocol-buffers/docs/overview [2] http://thrift.apache.org/static/files/thrift-20070401.pdf Getting old! :-) Thanks for the heads up.
Re: A Discussion of Tuple Syntax
On Tuesday, 20 August 2013 at 00:29:17 UTC, H. S. Teoh wrote: Sounds like you're confused about what built-in tuples are (and you wouldn't be the first -- they're rather confusing things). I know the difference between std.typecons.Tuple and the built-in tuples. What I'm confused about is I thought that the main objective of the tuple literal syntax (destructuring/pattern matching aside) was a means to have first-class tuples. That is, tuples that have their own literal syntax, have a list of valid operations that can be done on them, can be passed to functions, and can be returned from functions. Whether this is implemented as a syntactic sugar for std.typecons.Tuple, syntactic sugar for the built-in tuples, or a primitive type analogous to int, char, double[], etc. is not particularly important. It's becoming clear, now, that everyone has a different idea about what tuples should comprise, and I believe I have a better understanding of why this issue has yet to be solved. The answer is, this code makes no sense, because you can't return template arguments from a function. It makes as much sense as returning a function's signature from a function. You can't do that, because a function's signature isn't a runtime value that can be returned. Similarly: return TypeTuple!(int, 1); doesn't really make sense. The tuple (int, 1) isn't a runtime value that you can return from a function. It's a compile-time concept that doesn't exist at runtime. All which makes it not first-class. Let's return, then, to Kenji's DIP, and ask how the semantics he described can be implemented in D, unless someone objects to some facet of the DIP, at which point it can be worked out.
Re: A Discussion of Tuple Syntax
On Tuesday, 20 August 2013 at 00:28:47 UTC, Meta wrote: Yes, changing semantics is a bad thing, which is why I was originally thinking of the tuple syntax as sugar for std.typecons.Tuple. The proposed syntax takes a hit if it is just sugar for the compiler tuples. They will break in some cases when being passed to functions, and will still not be able to be returned from functions. It is not about sugar. It is about having entity in standard library to express concept that is built in into language and confusion it creates. Fixing semantics to allow _even more auto-expansion_ is a nice possible side effect. What you ask it is done by Tuple and there is nothing special about it - it is a struct, normal value type. One may be disappointed with relatively verbose syntax but it is not a real issue. But conflating it with built-in possible is simply impossible - if you even start thinking about syntax that does it, you probably need to re-read all documentation linked in this topic on tuple topic. Of course, we could have changed language in that regard - but this is a huge change, so complex that thinking about literal syntax is last thing we should do. And it does not seem to have much supporters to start with.
Re: Updates to the WindowsAPI translation instructions; D2 only?
On 01/08/2013 21:59, Stewart Gordon wrote: - Just use the D const pointer syntax where we need it, rather than this CPtr template that was made for D1 compatibility. Now implemented. - Declare all constants as enums, in order to force inlining. Now in the translation instructions, but most modules still need to be updated to this policy. I have made Windows XP the default version. Version Windows2000 is still available for anybody who wants to target Win2K using a third-party compiler (does GDC still generate W2K-compatible code?) but no older versions are supported. And for anyone who wants to build old D1 Windows apps, I have placed a snapshot of the bindings from before this work began here: http://pr.stewartsplace.org.uk/d/legacy/win32.zip Stewart. -- My email address is valid but not my primary mailbox and not checked regularly. Please keep replies on the 'group where everybody may benefit.
Re: Possible solution to template bloat problem?
Well, I'm afraid that's what templates are. One (or the compiler)
fills them in and that's it.
In other words: Templates are compile time while (real) generics
are run time. This basically comes down to have some way of
designating classes as, for instance, comparable and then either
running along the object chain comparing all built in objects
(with built in compare functionality) or having a compare
implemented (Of course, there is also arithmetic functions, etc.).
While this sounds great it actually carries some code weight
("bloat") with it, too because all that functionality must be
somewhere. It gets (relatively) cheaper though when being heavily
used.
Re: A Discussion of Tuple Syntax
On Tuesday, 20 August 2013 at 00:13:24 UTC, Dicebot wrote: No. No. Absolutely no. What you want is simply syntax sugar for std.typecons.Tuple - it is not worth any language change, contrary to semantical issues with built-in tuples. Auto-expansion and integration with function/template parameter lists is what makes D built-in tuple that useful and it should stay so with hypothetical tuple literals. Yes, changing semantics is a bad thing, which is why I was originally thinking of the tuple syntax as sugar for std.typecons.Tuple. The proposed syntax takes a hit if it is just sugar for the compiler tuples. They will break in some cases when being passed to functions, and will still not be able to be returned from functions.
Re: A Discussion of Tuple Syntax
On Tue, Aug 20, 2013 at 02:14:28AM +0200, Meta wrote:
> On Tuesday, 20 August 2013 at 00:03:48 UTC, Andrei Alexandrescu
> wrote:
> >On 8/19/13 4:48 PM, Meta wrote:
> >>I don't necessarily want built-in syntax for a library type, but
> >>making tuples first-class would be nice. I mean, it's a bummer that
> >>they can't be returned from functions. That should definitely be
> >>changed.
> >
> >return tuple(1, "a");
>
> That's not a TypeTuple, though, it's a built-in tuple.
Sounds like you're confused about what built-in tuples are (and you
wouldn't be the first -- they're rather confusing things). They are
perhaps best thought of as template argument lists. As such, they have
no runtime value or, as Andrej puts it, they have no ABI. So it doesn't
make sense to return them from a function. What should be the meaning,
for example, of:
template fun(A...) {
auto fun() {
return A;
}
}
?
The answer is, this code makes no sense, because you can't return
template arguments from a function. It makes as much sense as returning
a function's signature from a function. You can't do that, because a
function's signature isn't a runtime value that can be returned.
Similarly:
return TypeTuple!(int, 1);
doesn't really make sense. The tuple (int, 1) isn't a runtime value that
you can return from a function. It's a compile-time concept that doesn't
exist at runtime.
T
--
MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs
Re: A Discussion of Tuple Syntax
On 8/19/13 5:14 PM, Meta wrote:
On Tuesday, 20 August 2013 at 00:03:48 UTC, Andrei Alexandrescu wrote:
On 8/19/13 4:48 PM, Meta wrote:
I don't necessarily want built-in syntax for a library type, but making
tuples first-class would be nice. I mean, it's a bummer that they can't
be returned from functions. That should definitely be changed.
return tuple(1, "a");
That's not a TypeTuple, though, it's a built-in tuple.
void main()
{
writeln(func());
}
TypeTuple!(int, string) func()
{
return tuple(1, "a"); //Error
}
Nor does it work the other way around:
Tuple!(int, string) func()
{
return TypeTuple!(1, "a"); //Error
}
How would this work for some hypothetical built-in syntax?
#(int, string) func()
{
return tuple(1, "a"); //Error?
}
Why would it be necessary to return an object of type TypeTuple (i.e.
template tuple)? It has no state.
Andrei
Re: Why I chose D over Ada and Eiffel
On 20/08/13 06:18, Ramon wrote: Falling over the famous Ariane 5 article I looked at Eiffel. I have to confess that I almost feel in love. Eiffel felt just right and Prof. Meyers books convinced me again and again - Yesss, that's the way I'd like to work and develop software. Unfortunately, though, Prof Meyer and ISE (the Eiffel company) made some errors, too, and in a major way. For a starter that whole Eiffel world is pretty much a large beautiful castle ... inmidst a desert. Theoretically there are different compilers, factually, however, ISE's Eiffelstudio is the only one; the others are either brutally outdated or non-conforming or weird niche thingies or eternally in alpha, or a mixture of those. And Eiffelstudio costs north of 5.000 us$. Sure there is a GPL version but that is available only for GPL'ed programs. Next issue: Eiffels documentation is plain lousy. Yes, there are some 5 or so books but those are either purely theoretical or very outdated or both. Yes there is lots of documentation online but most of it basically is luring sales driven "Look how easy it is with Eiffel" stuff. And there is a doxygen like API doc which is pretty worthless for learning how to practically use the language. Furthermore, while Eiffel comes with a lot on board there still is much missing; just as an example there are no SSL sockets which nowadays is a killer. I found similar issues with Eiffel plus I was turned off by the OOP only factor. Programming needs to be more flexible than that. BTW using Eiffel was where I first realized that contracts would never be as useful as I hoped. They're still useful and I still use them but they're not as expressive as I'd hoped for (neither are D's). In reality, they're just highly targeted unit tests. I think my disappointment stems from the fact I used to write Z specifications and I would liked to have contracts that were the equivalent. Peter
Re: A Discussion of Tuple Syntax
On Tuesday, 20 August 2013 at 00:14:30 UTC, Meta wrote: That's not a TypeTuple, though, it's a built-in tuple. s/built-in tuple/library tuple
Re: A Discussion of Tuple Syntax
On Tuesday, 20 August 2013 at 00:03:48 UTC, Andrei Alexandrescu
wrote:
On 8/19/13 4:48 PM, Meta wrote:
I don't necessarily want built-in syntax for a library type,
but making
tuples first-class would be nice. I mean, it's a bummer that
they can't
be returned from functions. That should definitely be changed.
return tuple(1, "a");
That's not a TypeTuple, though, it's a built-in tuple.
void main()
{
writeln(func());
}
TypeTuple!(int, string) func()
{
return tuple(1, "a"); //Error
}
Nor does it work the other way around:
Tuple!(int, string) func()
{
return TypeTuple!(1, "a"); //Error
}
How would this work for some hypothetical built-in syntax?
#(int, string) func()
{
return tuple(1, "a"); //Error?
}
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 23:55:32 UTC, Meta wrote:
On Monday, 19 August 2013 at 23:48:36 UTC, Meta wrote:
...
An addendum:
void main()
{
//Prints 1
writeln(func(TypeTuple!(1, 2)));
}
int func(int i, int j)
{
return i;
}
This is bad and should never be allowed with some hypothetical
tuple literal syntax. The desired behaviour is:
void main()
{
//Error: func is not callable using argument types (#(int,
int))
writeln(func(#(1, 2));
}
*Unless* you use .expand/[] (pick your poison):
void main()
{
writeln(func(#(1, 2).expand)); //Or #(1, 2)[]
}
No. No. Absolutely no. What you want is simply syntax sugar for
std.typecons.Tuple - it is not worth any language change,
contrary to semantical issues with built-in tuples.
Auto-expansion and integration with function/template parameter
lists is what makes D built-in tuple that useful and it should
stay so with hypothetical tuple literals.
Re: Why I chose D over Ada and Eiffel
On Monday, 19 August 2013 at 21:19:05 UTC, H. S. Teoh wrote: Honestly, while OO definitely has many things to offer, I think its proponents have a tendency to push things a little too far. There are things for which OO isn't appropriate, ... Nope, I don't belong to the OOP fanatics in the sense of "everything must be a class"; actually that's one of my critical remarks on Eiffel. But, no doubt, OOP is an absolute must have. I remember my (seen from today pathetic) desperate attempts to use C at least in a somewhat OO way (abusing structs). ... C++ tries to do OO but fails miserably because it insisted on backward-compatibility with C. I'm not sure that I can agree on that. I'll elaborate somewhat on this issue for reasons that directly touch D. Actually C backward compatibility *could* have been implemented in D, too, if at quite some cost for the implementers; after all it's no coincidence that D feel pretty much "at home" for a C programmer - although the D people probably came to the conclusion that being similar enough was enough or even better than to go for full C compatibility (= capable to compile C code) and rightly so. I'm sure that basically every C programmer looking at another language doesn't look for another C but rather for something he can quickly master to a useable degree; otherwise he wouldn't be looking for another language in the first place. As far as I'm concerned D's superiority over C++ has another reason: D was conceived from a _pragmatic approach_. While it's a great thing to have scientists to design new paradigms and concepts it's, I'm convinced, a bad idea to have them actually go to the end; the perspectives, weighting of criteria and other issues usually happen to be a very different mix from what practical use would suggest. Just look at C. We didn't miss so much new concepts and paradigms (except maybe OO) but rather were swearing at quite pragmatic aspects like lots of housekeeping overhead for resizing an array and many other things and at stupid problems related to pointers (like array being automatically being passed as pointers). I remember quite well that when wanting proper error handling, some logging and maybe message strings in 2 languages one quickly ended up with most code not related to the algorithm or problem at hand but to those housekeeping chores and alike. In summary my impression is that C++ was created by scientists who somehow shoehorned a set of (what they considered) concepts and paradigms into a language that looked good in lectures - but they didn't care sh*t about compiler writers and actual users who had to solve actual problems. While many considered STL a breakthrough milestone for mankind I personally, Pardon me, always considered it a) a weird mess and b) a confession that C++ was f*cked up. Y'know, out on the street the word is that C is outdated and dangerous and hard to maintain, and that C++ is better. But my experience -- and yours -- seems to show otherwise. You're not the first one that found C++ lacking. At my day job, we actually migrated a largish system from C++ back into C because the C++ codebase was overengineered and suffered from a lot of the flaws of C++ that only become evident once you move beyond textbook examples. (C++ actually looks rather nice in textbooks, I have to admit, but real-life code is sadly a whole 'nother story.) See my point above and: I couldn't care less what's the current hype in Dr.Dobbs or Computer Language (anyone remembers that?) or for that matter the "word on the street". Actually I tought C at that time and I remember to comment students remarks concerning OO, C++ and the like along this line "C basically is a - pretty well done - attempt to create a cross platform assembler with quite some comfort". After all, this shouldn't be forgotten, C was created to use the wonderful new PDP11 (by brilliant men who had understood that a) there would be other architectures and systems to follow and b) one shouldn't have to learn 10 assemblers for 10 systems. C++'s proponents stating that C++ was meant to be an better C with OO on top never had any credibility considering the background and origin and raison d'etre of C as far as I'm concerned. - practically useable modern Arrays? Check. And ranges, too. And very smartly thought up and designed. Great. Time will tell, but I believe ranges may be one of the most significant innovations of D. It makes writing generic algorithms possible, and even pleasant, and inches us closer to the ideal of perfect code reuse than ever before. I'm afraid I can't follow your "ranges making generic algorithms possible" but I do agree that ranges are among the more important strengths of D, greatly contributing to useability and productivity. As for generics I still need to learn more about D but from first impressions and comments I'm not sure that D has reached a final and
Re: GPGPU and D
On Sunday, 18 August 2013 at 08:40:33 UTC, Russel Winder wrote: Luminousone, Atash, John, Thanks for the email exchanges on this, there is a lot of good stuff in there that needs to be extracted from the mail threads and turned into a "manifesto" type document that can be used to drive getting a design and realization together. The question is what infrastructure would work for us to collaborate. Perhaps create a GitHub group and a repository to act as a shared filestore? I can certainly do that bit of admin and then try and start a document summarizing the email threads so far, if that is a good way forward on this. I just downloaded cl4d and tried it: The non-derelict example compiles and runs, straight out of the box :) Also, I found this fork: https://github.com/vuaru/cl4d which appears to have swapped out the static bindings for the dynamic ones in derelict.
Re: Updates to the WindowsAPI translation instructions; D2 only?
On 02/08/2013 06:51, Sönke Ludwig wrote:
I would seriously take into consideration to just drop the "A" versions. D is
unicode by
nature, the "W" versions are supported by all NT systems (since Windows 95
using MSLU),
and using an ANSI version of a function also just begs for bugs if typed as
"char*"
instead of "ubyte*". Many newer functions also just have a single wide string
variant.
Maybe, but there are probably a number of programs out there that still use ANSI for
backward compatibility reasons.
IMO this is just legacy cruft that was maybe still useful in times when
supporting Windows
95 was important and MSLU had to be installed as an explicit add-on, but for
nothing else
really (although frequently used in C programs because it saves typing an
additional
character: "" vs. L"" or even _T("")).
Also switching API based on a version statement always introduces a chance to
break
interoperability of two libraries that require the version to be set
differently.
I'm not sure what else some library might reasonably define version(Unicode) to mean that
might cause a conflict
Stewart.
--
My email address is valid but not my primary mailbox and not checked regularly. Please
keep replies on the 'group where everybody may benefit.
Re: A Discussion of Tuple Syntax
On 8/19/13 4:48 PM, Meta wrote: I don't necessarily want built-in syntax for a library type, but making tuples first-class would be nice. I mean, it's a bummer that they can't be returned from functions. That should definitely be changed. return tuple(1, "a"); Andrei
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 23:48:36 UTC, Meta wrote:
...
An addendum:
void main()
{
//Prints 1
writeln(func(TypeTuple!(1, 2)));
}
int func(int i, int j)
{
return i;
}
This is bad and should never be allowed with some hypothetical
tuple literal syntax. The desired behaviour is:
void main()
{
//Error: func is not callable using argument types (#(int,
int))
writeln(func(#(1, 2));
}
*Unless* you use .expand/[] (pick your poison):
void main()
{
writeln(func(#(1, 2).expand)); //Or #(1, 2)[]
}
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 18:40:58 UTC, H. S. Teoh wrote: Case in point. :) So we're actually talking at cross purposes here. Bearophile & Meta et al want native syntax for *runtime* tuples (i.e. std.typecons.Tuple -- sorry for the mixup with std.range in my earlier posts), but you're talking about native syntax for alias tuples (aka TypeTuples). Two completely different things. Now that I reread Kenji's DIP for a third time, I see/recall that his intention was for this syntax to be for alias tuples. In that case, wouldn't this necessitate a change in semantics? Will these alias tuples using built-in syntax still auto-expand? I agree that we shouldn't be making built-in syntax for a library type. If anything, any dedicated syntax should be reserved for alias tuples (aka std.typetuple.Typetuple). Or, at the very least, rename TypeTuple to AliasTuple. I don't necessarily want built-in syntax for a library type, but making tuples first-class would be nice. I mean, it's a bummer that they can't be returned from functions. That should definitely be changed. Conflating these two concepts has led to endless confusion, which is why I insisted on addressing this issue before we even begin to talk about syntax. Otherwise we're going nowhere. T
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Monday, 19 August 2013 at 22:16:39 UTC, ProgrammingGhost wrote: Is it true? Are you able to read a line (or two) at once? I have been doing it since early school days and was quite surprised to find out later that it is not the common case. Well, when reading technical literature I often come back and re-read some intense paragraphs carefully word-by-word but it is more like fallback. And yes, I do try to organize the code in such way that going quickly up-down through it is possible.
Re: A Discussion of Tuple Syntax
ixid: Are singleton tuples actually useful for anything? They are not much useful, but unless you want to outlaw them, you have to keep them in account when you design a syntax. Bye, bearophile
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 22:36:34 UTC, bearophile wrote: ixid: auto assoc_array = [1 : (2 : 3)]; // A tuple associative value auto assoc_array2 = [(1 : 2) : 3]; // A tuple associative key auto ternary = value? (1 : 2) : (3 : 4); // tuple values in a ternary operator It's nicer looking than #(). Are singleton tuples represented with (1:) ? Bye, bearophile Sure, why not? It looks happy enough. :) Are singleton tuples actually useful for anything?
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 18:43:37 UTC, Meta wrote: What does concatenating a tuple actually do? That is: auto a = #(1,2) ~ 3; //Result: a == #(1,2,3), right? auto b = a ~ #(4,5); //Is b == #(1,2,3,#(4,5)) or is b == #(1,2,3,4,5)? I think it should work the same as with arrays. So: auto a = #(1, 2) ~ 3; //Error: 3 is not a tuple auto a = #(1, 2) ~ #(3); //Result: #(1, 2, 3), just like an array auto b = a ~ #(4, 5); //Result: #(1, 2, 3, 4, 5). Again, like arrays. I was being dumb, [1, 2] ~ 3 is of course valid for arrays, so that should work for tuples as well. Furthermore, #(1, 2) ~ "a" should be valid, and will result in #(1, 2, "a"). I think keeping the same semantics as arrays would be the best way to do it. I think it nicely follows the principle of least astonishment. If you wanted to explicitly append a tuple and have it nested, you'd need to do: auto b = a ~ #(#(4, 5)); Which is messy, but at least it's explicit about what is going on. The tricky part of this that I forgot to mention is that you can't do this with arrays, so we're in unknown territory, but I think this is sensible. Again, it's quite ugly, but oh well.
Re: A Discussion of Tuple Syntax
On 2013-08-19 17:04, Meta wrote: On Monday, 19 August 2013 at 21:03:50 UTC, Andrei Alexandrescu wrote: b) syntactic support for ignoring certain members in a destructuring - is that really needed? auto (a, ?, c) = functionReturningTupleOrStaticArrayWith3Elements(); In fairness, it is very common in other languages with pattern matching/destructuring. Off the top of my head I can think of Haskell, ML, Racket, Javascript (destructuring only) and Rust. same in matlab. once destruction->auto assignment is available, (future) library functions will make heavy use of it, e.g. statistics functions returning lots of parameters/characteristics for a dataset. more often than not one is only interested in a few. /det
Re: A Discussion of Tuple Syntax
ixid: auto assoc_array = [1 : (2 : 3)]; // A tuple associative value auto assoc_array2 = [(1 : 2) : 3]; // A tuple associative key auto ternary = value? (1 : 2) : (3 : 4); // tuple values in a ternary operator It's nicer looking than #(). Are singleton tuples represented with (1:) ? Bye, bearophile
Re: When compiling multiple source files
On Monday, 19 August 2013 at 17:35:39 UTC, John Colvin wrote:
On Monday, 19 August 2013 at 17:15:35 UTC, ProgrammingGhost
wrote:
On Monday, 19 August 2013 at 11:01:54 UTC, Jacob Carlborg
wrote:
The compiler will start compiling the files passed on the
command line. It will read the files asynchronously and then
lex, parse build an AST and do semantic analyze.
When the semantic analyze is done it will have access to all
import declarations. It basically starts the same processes
for all these imports, recursively.
The reason for waiting until semantic analyze is done because
you can have code looking like this:
mixin("import foo;");
The expansion of the mixin and other similar features are
done in the semantic analyze phase.
So everything is parsed once and kept in memory until the
compiler finish every source file? Is there any ram problems
when compiling large codebases?
Unfortunately, yes, if you give dmd a very large number of
files all at once, it will chew through all your free RAM. But
dmd does support separate compilation:
$dmd file1.d -c
$dmd file2.d -c
$dmd file1.o file2.o
which alleviates the problem.
My experience with D is limited. Are libraries the same as C
libraries? From my understanding the linker figures that part
out and the compiler needs a separate file for the definition.
If I build a library in D is it the same as a C library or
different which includes function definitions?
Sorry if I'm confused I know almost nothing about D. I stick
to .NET, java and C++
Libraries in D use the same formats as C/C++ libraries.
Is it possible that if I just try to compile 1 file it could
imports enough libraries that import/need the definitions for
additional large libraries which in turn also imports everything
causing ram issues? I'm sure in practice this will almost never
happen. But I don't doubt there are main libraries that use other
large libraries and everything imports/uses everything
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Sunday, 18 August 2013 at 17:28:16 UTC, Iain Buclaw wrote: On 18 August 2013 18:24, ProgrammingGhost wrote: On Sunday, 11 August 2013 at 18:25:02 UTC, Andrei Alexandrescu wrote: For a column of text to be readable it should have not much more than 10 words per line. Going beyond that forces eyes to scan too jerkily and causes difficulty in following line breaks. This. Also some people can read a line a second because they read downward instead of left to right. Although I heard this through hearsay Probably more like two lines at once, if they are reading a book. Reading code? I reckon you can read downwards on that. :) Is it true? Are you able to read a line (or two) at once?
Re: Why I chose D over Ada and Eiffel
On Monday, 19 August 2013 at 22:00:17 UTC, Walter Bright wrote: On 8/19/2013 2:17 PM, H. S. Teoh wrote: Time will tell, but I believe ranges may be one of the most significant innovations of D. It makes writing generic algorithms possible, and even pleasant, and inches us closer to the ideal of perfect code reuse than ever before. While not unique to D, I believe that ranges will become a killer feature - killer enough that languages that don't support pipeline programming will start looking like propeller driven airliners. We still have a ways to go yet - Phobos support for ranges is not ubiquitous - but ranges are the future. Is there an official "everything that sensibly can provide a range, should do" policy for phobos? If so, there's quite a bit of low-hanging fruit.
Re: Why I chose D over Ada and Eiffel
On 8/19/2013 3:10 PM, John Colvin wrote: On Monday, 19 August 2013 at 22:00:17 UTC, Walter Bright wrote: We still have a ways to go yet - Phobos support for ranges is not ubiquitous - but ranges are the future. Is there an official "everything that sensibly can provide a range, should do" policy for phobos? If so, there's quite a bit of low-hanging fruit. There is as far as I'm concerned. Note the holding back of std.serialization until it has full support for ranges.
Re: Possible solution to template bloat problem?
On Monday, 19 August 2013 at 20:23:46 UTC, H. S. Teoh wrote:
With D's honestly awesome metaprogramming features, templates
are liable
to be (and in fact are) used a LOT. This leads to the
unfortunate
situation of template bloat: every time you instantiate a
template, it
adds yet another copy of the templated code into your object
file. This
gets worse when you use templated structs/classes, each of
which may
define some number of methods, and each instantiation adds yet
another
copy of all those methods.
This is doubly bad if these templates are used only during
compile-time,
and never referenced during runtime. That's a lot of useless
baggage in
the final executable. Plus, it leads to issues like this one:
http://d.puremagic.com/issues/show_bug.cgi?id=10833
While looking at this bug, I got an idea: what if, instead of
emitting
template instantiations into the same object file as
non-templated code,
the compiler were to emit each instantiation into a separate
static
*library*? For instance, if you have code in program.d, then the
compiler would emit non-templated code like main() into
program.o, but
all template instantiations get put in, say, libprogram.a. Then
during
link time, the compiler runs `ld -oprogram program.o
libprogram.a`, and
then the linker will pull in symbols from libprogram.a that are
referenced by program.o.
If we were to set things up so that libprogram.a contains a
separate
unit for each instantiated template function, then the linker
would
actually pull in only code that is actually referenced at
runtime. For
example, say our code looks like this:
struct S(T) {
T x;
T method1(T t) { ... }
T method2(T t) { ... }
T method3(T t) { ... }
}
void main() {
auto sbyte = S!byte();
auto sint = S!int();
auto sfloat = S!float();
sbyte.method1(1);
sint.method2(2);
sfloat.method3(3.0);
}
Then the compiler would put main() in program.o, and *nothing
else*. In
program.o, there would be undefined references to
S!byte.method1,
S!int.method2, and S!float.method3, but not the actual code.
Instead,
when the compiler sees S!byte, S!int, and S!float, it puts all
of the
instantiated methods inside libprogram.a as separate units:
libprogram.a:
struct_S_byte_method1.o:
S!byte.method1
struct_S_byte_method2.o:
S!byte.method2
struct_S_byte_method3.o:
S!byte.method3
struct_S_int_method1.o:
S!int.method1
struct_S_int_method2.o:
S!int.method2
struct_S_int_method3.o:
S!int.method3
struct_S_float_method1.o:
S!float.method1
struct_S_float_method2.o:
S!float.method2
struct_S_float_method3.o:
S!float.method3
Since the compiler doesn't know at instantiation time which of
these
methods will actually be used, it simply emits all of them and
puts them
into the static library.
Then at link-time, the compiler tells the linker to include
libprogram.a
when linking program.o. So the linker goes through each
undefined
reference, and resolves them by linking in the module in
libprogram.a
that defines said reference. So it would link in the code for
S!byte.method1, S!int.method2, and S!float.method3. The other 6
instantiations are not linked into the final executable,
because they
are never actually referenced by the runtime code.
So this way, we minimize template bloat to only the code that's
actually
used at runtime. If a particular template function
instantiation is only
used during CTFE, for example, it would be present in
libprogram.a but
won't get linked, because none of the runtime code references
it. This
would fix bug 10833.
Is this workable? Is it implementable in DMD?
T
Without link-time optimisation, this prevents inlining doesn't it?
Re: Possible solution to template bloat problem?
On Monday, 19 August 2013 at 22:11:39 UTC, John Colvin wrote: Without link-time optimisation, this prevents inlining doesn't it? It does not _prevent_ inlining, but it breaks incremental builds in case inlining has ever happened.
Re: A Discussion of Tuple Syntax
On Friday, 16 August 2013 at 23:48:53 UTC, bearophile wrote:
Meta:
Andrei/Walter didn't want to merge that pull request without a
full consideration of the different design issues involved,
which in retrospect was a good decision.
I agree that before adding some new syntax you have to think
well.
- {a, b} is not as pretty, but it's not that bad of an
alternative (though it may still have issues as well)
It has technical issues, they were discussed in one of the last
threads. Such problems should be added in a note in the DIP32,
so they don't get lost in time.
- #(a, b) is unambiguous and would probably be the easiest
option. I don't think it looks too bad, but some people might
find it ugly and noisy
It looks nice (but I don't know if it's technically usable), I
have added it at the end of the list of alternative syntaxes:
http://wiki.dlang.org/DIP32#Use_case_of_uniform_tuple_syntax
I personally think #(a, ?) or #(a, *) would be best, but all
that's really necessary is a symbol that cannot also be an
identifier.
I think ? is clear, unambiguous, etc, and I like it. The * is
already used for pointers, product, dereferencing, ** is used
for pow, so it's better to not add further meanings to it.
- Concatenating tuples with ~. This is nice to have, but not
particularly important.
In theory I like this operation, but in practice in my D code I
don't need it often, so I think it should be left out, for
later.
In Python I sometimes concatenate tuples, but in such use cases
they are essentially immutable dynamically typed arrays, losing
their positional meaning.
Tuples could also be used in switch/case statements, to support
a very basic form of pattern matching. See also a standard
method named "unapply" I have discussed a bit here, coming from
Scala language, that is a very simple solution to solve a
significant problem:
http://d.puremagic.com/issues/show_bug.cgi?id=596
Bye,
bearophile
What about using : as people had intended to use the comma
operator?
uint a, b;
(a : b) = (1 : 2);
(a : b) = tupleReturningFunction;
auto c = (1 : (2 : 3)); // A tuple containing a tuple
auto d = (1 : ((2 : 3) : (4 : 5))); // a tuple with a tuple of
tuples as a member
auto assoc_array = [1 : (2 : 3)]; // A tuple associative value
auto assoc_array2 = [(1 : 2) : 3]; // A tuple associative key
auto ternary = value? (1 : 2) : (3 : 4); // tuple values in a
ternary operator
It's nicer looking than #().
Re: Possible solution to template bloat problem?
On 8/19/13, H. S. Teoh wrote: > Plus, DMD really needs to stop stripping paths from object files *by > default* Meanwhile give your vote to: https://github.com/D-Programming-Language/dmd/pull/1871
Re: Why I chose D over Ada and Eiffel
On 8/19/2013 2:17 PM, H. S. Teoh wrote: Time will tell, but I believe ranges may be one of the most significant innovations of D. It makes writing generic algorithms possible, and even pleasant, and inches us closer to the ideal of perfect code reuse than ever before. While not unique to D, I believe that ranges will become a killer feature - killer enough that languages that don't support pipeline programming will start looking like propeller driven airliners. We still have a ways to go yet - Phobos support for ranges is not ubiquitous - but ranges are the future.
Re: Possible solution to template bloat problem?
On Monday, 19 August 2013 at 21:33:08 UTC, H. S. Teoh wrote: Hmm. It'd be nice if this could be made to work. One thing I'm not very happy with in D is the sheer size of the executables even for relatively simple programs. If unused symbols could be stripped during linking, this would help a lot. TBH, I was waiting until dust with DDMD settles down a bit simply reading sources, but going to get back pretty soon. Help is welcome, I can provide plenty of information to start with ;)
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 21:03:50 UTC, Andrei Alexandrescu
wrote:
I'm saying that there's a mix of useful stuff and just
syntactic additions that are arguably less so. In my opinion:
a) destructuring tuples in auto declarations - good to have:
auto (a, b, c) =
functionReturningTupleOrStaticArrayWith3Elements();
b) syntactic support for ignoring certain members in a
destructuring - is that really needed?
auto (a, ?, c) =
functionReturningTupleOrStaticArrayWith3Elements();
In fairness, it is very common in other languages with pattern
matching/destructuring. Off the top of my head I can think of
Haskell, ML, Racket, Javascript (destructuring only) and Rust.
This syntax is more important when pattern matching, but also
seems to be almost universally used in destructuring. From the
DIP:
switch (tup) {
case {1, 2}:
case {$, 2}: //Don't care what the first value is, only match
on second
case {1, x}:
default:
}
You could just replace {$, 2} with {x, 2} and never use x, but
this creates the problem that Bearophile mentioned.
auto t1 = #(5, "hello", 1.5); //Fine
auto #(_, _, x) = t1; //Dammit, can't use _ twice as it's a
variable
If you replace _ with throwaway variable names, it becomes much
less clear (IMO) exactly what is going on. Any programmer reading
your code would have to examine the function to see if the
bindings introduced are ever used, or if they are just throwaways.
Maybe it's unproductive to argue over the colour of the bike
shed, but we need to know whether it's worth adding windows.
Re: Possible solution to template bloat problem?
On Monday, 19 August 2013 at 21:33:08 UTC, H. S. Teoh wrote: Inside this archive, template instantiations are organized according to the module hierarchy -- i.e., if you import std.stdio and use writeln, the instantiation of writeln will be put into std/stdio/writeln_*.o in templates.a, NOT the root module. Ok. Now you change the signature of writeln. Incremental rebuild. Will you do reflection upon the object file in templates.a to get the list of required instances? Or rebuild all modules that import std.stdio even indirectly? Most likely latter, because it also could have been inlined in several places and those need to be rebuilt too. To track modules that actually use that template instance one needs implementation from my proposal #1 anyway :(
Re: Why I chose D over Ada and Eiffel
Ramon: not having multiple inheritance is a major minus with me. D seems to compensate quite nicely by supporting interfaces. D is also supposed to gain multiple "alias this", currently only one is supported. Bye, bearophile
Re: Possible solution to template bloat problem?
On Mon, Aug 19, 2013 at 10:37:35PM +0200, Dicebot wrote: > Just two words: "separate compilation". > > Any solution that is going to address template problem needs to > improve current state with such compilation model, not make it even > worse. I thought about that, actually. (I'm a fan of separate compilation, though the current state of D makes it more advantageous to compile everything in one go where possible.) There should be *one* static library where template instantiations are dumped. Let's call it templates.a for lack of a better name. Inside this archive, template instantiations are organized according to the module hierarchy -- i.e., if you import std.stdio and use writeln, the instantiation of writeln will be put into std/stdio/writeln_*.o in templates.a, NOT the root module. Furthermore, if a particular instantiation is already present in templates.a, then it is not duplicated, but simply replaced (I was going to say ignored, but replace is better in case templates.a contains leftovers from a previous compilation run). This eliminates duplicate instantiations of the same templates in multiple modules. > As an alternative, I have proposed one of two approaches (or both): > > 1) Stop dumping all symbols into root module supplied from the > command line. Emit symbols to object files that match modules they > were instantiated from. If symbol has no valid source point (== > constraint or CTFE) than don't emit it at all. +1. Plus, DMD really needs to stop stripping paths from object files *by default* -- now that we have package.d, this will blow up in ugly ways once you have templates in package.d that get instantiated and there are multiple packages with package.d. > 2) Create object files in format that allows usage of `ld > --gc-sections` (garbage collection of unused symbols upon linking). > Don't know if similar thing exists for Windows. Well, the reason I went for bare linker essentials was precisely to avoid platform-specific issues like this. But OTOH, on platforms that support the equivalent of --gc-sections, we could just emit template instantiations into separate sections instead of separate modules in a static library. The static library approach can serve as a fallback on platforms that don't support this. > Latter should be relatively easy to do but it is not cross-platform > and it does not help build systems with tracking rebuild conditions. > > Former feels like a proper approach and I have been working on it > (also @eskimor) for some time. But it is rather hard as relevant > code does not seem to track required information at all and probably > no one but Walter knows all minor details about its design. To sum > it up - I have not been able to produce a pull request that passes > the test suite so far (though I have put it on hold for some time, > going to return to this). Hmm. It'd be nice if this could be made to work. One thing I'm not very happy with in D is the sheer size of the executables even for relatively simple programs. If unused symbols could be stripped during linking, this would help a lot. T -- Political correctness: socially-sanctioned hypocrisy.
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 21:16:43 UTC, Brad Anderson wrote: On Monday, 19 August 2013 at 19:24:32 UTC, Timon Gehr wrote: On 08/19/2013 07:44 PM, H. S. Teoh wrote: Well, OK, whatever they're supposed to be called. Compiler-tuples, or expression tuples, or whatever. See, part of the problem is that they just don't have any good name that correctly conveys what they are. They are simply template argument lists. (http://wiki.dlang.org/The_D_Programming_Language/Seq) Nice short FAQ for one of the more confusing parts of D. The name "template argument list" clears things up quite a bit actually (but is too long for a type name). Is it your idea to use Seq instead of TypeTuple? Pretty heavy on the snark though :P
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 21:03:50 UTC, Andrei Alexandrescu wrote: I'm saying that there's a mix of useful stuff and just syntactic additions that are arguably less so. Wanted to note here that while discussing syntax at this moment is indeed mostly useless but playing with imaginary code snippets does help to understand what behavior people want to see and that can be used as a basis for formalizing semantics.
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 19:24:32 UTC, Timon Gehr wrote: On 08/19/2013 07:44 PM, H. S. Teoh wrote: Well, OK, whatever they're supposed to be called. Compiler-tuples, or expression tuples, or whatever. See, part of the problem is that they just don't have any good name that correctly conveys what they are. They are simply template argument lists. (http://wiki.dlang.org/The_D_Programming_Language/Seq) Nice short FAQ for one of the more confusing parts of D. The name "template argument list" clears things up quite a bit actually (but is too long for a type name). Is it your idea to use Seq instead of TypeTuple?
Re: Why I chose D over Ada and Eiffel
On Mon, Aug 19, 2013 at 10:18:04PM +0200, Ramon wrote:
[...]
> 25+ years ago I started with C. I loved it. But then I had a hacker
> attitude, considering "raw and tough" the only choice for a real man
> *g.
That was me about 20 years ago too. :)
> It took me more than 10 years to recognize (or allow myself to
> realize) that something was quite unsatisfying about C and that, as
> much as I understood the necessity of OO and strongly desired io
> employ it, C++ was not a solution but rather pretty much all
> disadvantages of C repeated and then a major nightmare added or,
> excuse my french, a major pain in the a**.
Honestly, while OO definitely has many things to offer, I think its
proponents have a tendency to push things a little too far. There are
things for which OO isn't appropriate, but in languages like Java, you
have to shoehorn *everything* into the OO mold, no matter what. This
leads to ridiculous verbosity like:
// Everything has to be a class, even if there's absolutely
// nothing about main() that acts like a class!
class MyLousyJavaProgram {
// Are you serious? All this boilerplate just to declare
// the main program?!
public static void main(String[] args)
throws IOException
{
// What, this long incantation just to print
// "Hello, world!"??
System.err.println("Hello world!");
}
}
The signal-to-noise ratio in this code is about 1 : 6 (1 line of code
that actually does the real work, 6 lines of boilerplate). Compare the
equivalent D program:
import std.stdio;
void main() {
writeln("Hello world!");
}
Even C isn't as bad as the Java in this case.
But I digress. Coming back to the point, C++ tries to do OO but fails
miserably because it insisted on backward-compatibility with C. This was
a smart move in the short term, since it helped C++ adoption from the
hordes of C coders at the time, but in the long run, this has hurt C++
so much by making it impossible to fix some of the fundamental design
mistakes that leads to C++ being the ugly monstrosity it is today.
[...]
> By coincidence (or fate?) I found myself confronted with a project
> demanding extreme reliability and reusability requirements. As much
> as I tried, C++ just couldn't cut it. One major reason might be
> interesting (or well known) to some of you: You basically can't rely
> in third party C++ code. Not meaning to talk bad about anyone but
> it's my bloody experience. Maybe it's because C++ makes it so hard
> to actually develop and engineer software (rather than hacking),
> maybe because C++ attracts guys like my earlier self (the cool C/C++
> hacker), whatever the reason may be, that's what I experienced.
Y'know, out on the street the word is that C is outdated and dangerous
and hard to maintain, and that C++ is better. But my experience -- and
yours -- seems to show otherwise. You're not the first one that found
C++ lacking. At my day job, we actually migrated a largish system from
C++ back into C because the C++ codebase was overengineered and suffered
from a lot of the flaws of C++ that only become evident once you move
beyond textbook examples. (C++ actually looks rather nice in textbooks,
I have to admit, but real-life code is sadly a whole 'nother story.)
[...]
> So, I desperately looked for something that would offer at least
> some major goodies lik DBC and would otherwise at least not stand in
> the way of proper software engineering.
>
> Well, that single feature, Design By Contract, led me toward D.
>
> - practically useable modern Arrays? Check.
> And ranges, too. And very smartly thought up and designed. Great.
Time will tell, but I believe ranges may be one of the most significant
innovations of D. It makes writing generic algorithms possible, and even
pleasant, and inches us closer to the ideal of perfect code reuse than
ever before.
> - Strings? Check
> Plus UTF, too. Even UTF-8, 16 (a very practical compromise in my
> minds eye because with 16 bits one can deal with *every* language
> while still not wasting memory).
Yeah, in this day and age, not having native Unicode support is simply
unacceptable. The world has simply moved past the era of ASCII (and the
associated gratuitously incompatible locale encodings). Neither is the
lack of built-in strings (*cough*C++*cough*).
> - DBC? Check
> And once more the creators of D don't simply address one issue but
> do it elegantly and, even better, sonsistently by throwing in a nice
> use cases solution, too. Great!
Hmm. I hate to burst your bubble, but I do have to warn you that DbC in
D isn't as perfect as it could be. The *language* has a pretty good
design of it, to be sure, but the current implementation leaves some
things to be desired. Such as the fact that contracts are run inside the
function ra
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 20:51:47 UTC, Andrei Alexandrescu wrote: Normal alias. Yah, perhaps "template tuples" are more descriptive. And how would you call _instance_ of template tuple then? (which is also built-in tuple but not template tuple)
Re: Ideas for a brand new widget toolkit
I suggest to first find out what we really want (and therefore who "we" is). It seems to me that there are basically 3 groups: - looking for some kind of GUI-kit that is less massive than gtk, qt, etc. and runs pretty everywhere. Need addressed: Well, sometimes a GUI is needed. A no frills basic thingy will do; most importantly it must run everywhere and more or less feel like the native GUI. One approach: D'ize Fox - Looking for sophisticated GUI, possibly mainly for games, video etc. Need addressed: Graphics intense applications. Speed is important. - Add a GUI toolkit to D Need addressed: D should have a GUI toolkit anyway. Why not create a major one and do it a) the D way and b) properly, possibly attracting more users to D? Some remarks in no special order: - Doing something HTML (ideally 5) based looks very attractive and cross plattform. It brings with it, however, either the need for a built in http server and the interface app/server - or - an HTML component which again needed obe based on some GUI kit. - Whatever we come up with should use native controls where existing and otherwise simulate them using other more basic native controls. This sounds ugly, can, however, actually be a major chance and interesting approach. - Simply creating yet another GTK or QT is unattractive - they already exist and so do bindings to D (if I'm not mistaken. Otherwise those bindings can be created) - We should avoid some errors made by others and prepare for environmental changes (like X possibly being replace by wayland). In summary I'd consider to create - something new (rather than creating a, say, fox binding) - that starts simple, already addressing many needs - is designed in a way as to allow for some unobtrusive http binding (meaning: usually it runs by itself but it *can* - without breaking ones arm - also work through http) - is based on a clearly defined set of basic widgets that are commonly available in all major targets (X, Windows, mac, possibly android, etc) - is designed in a modular way so as to provide a) a basic GUI kit and b) - optionally - extensions or a "large" kit version. Reasoning: in 80% of cases a gui is needed simply as a gui interface for whatever programm. Sometimes, though, more is needed like e.g. a video widget. This a) eases design and development and b) is attractive because pretty every existing solution is either smallish (often too small) or a monster (often way to big) - could, in the long run, offer an HTML component so as to make HTML targets self hosting yet keep the http option open for new operating systems. My first target would be something like "designing a new 'fox' fully using D's superior capabilities and doing that along the lines I listed above". In other words: Let's scratch some itching that is a) common and b) not yet properly addressed by what is available. regards - Ramon
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 20:46:02 UTC, Andrei Alexandrescu wrote: It's stuff like this that's just useless and gives a bad direction to the whole discussion. There's hardly anything wrong with auto x = t1[2] or auto gr = t1[1], but once the bikeshed is up for painting, the rainbow won't suffice. I started this discussion to build on Kenji's DIP, which discusses destructuring and pattern matching syntax in addition to tuple literal syntax, as well as the previous discussion that's already gone on in the two "DIP discussion" threads. Are you saying that you dislike the destructuring/pattern matching discussion as a whole? I'm saying that there's a mix of useful stuff and just syntactic additions that are arguably less so. In my opinion: a) destructuring tuples in auto declarations - good to have: auto (a, b, c) = functionReturningTupleOrStaticArrayWith3Elements(); b) syntactic support for ignoring certain members in a destructuring - is that really needed? auto (a, ?, c) = functionReturningTupleOrStaticArrayWith3Elements(); Andrei
Re: A Discussion of Tuple Syntax
Andrei Alexandrescu: It's stuff like this that's just useless and gives a bad direction to the whole discussion. There's hardly anything wrong with auto x = t1[2] or auto gr = t1[1], but once the bikeshed is up for painting, the rainbow won't suffice. I was just explaining why _ can't be used as wildcard (unless you also make _ a not valid variable name), it wasn't meant to be an example of why wildcards are useful in the first place. Bye, bearophile
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 20:46:02 UTC, Andrei Alexandrescu wrote: It's stuff like this that's just useless and gives a bad direction to the whole discussion. There's hardly anything wrong with auto x = t1[2] or auto gr = t1[1], but once the bikeshed is up for painting, the rainbow won't suffice. I started this discussion to build on Kenji's DIP, which discusses destructuring and pattern matching syntax in addition to tuple literal syntax, as well as the previous discussion that's already gone on in the two "DIP discussion" threads. Are you saying that you dislike the destructuring/pattern matching discussion as a whole?
Re: A Discussion of Tuple Syntax
On 8/19/13 1:41 PM, Dicebot wrote: On Monday, 19 August 2013 at 20:36:10 UTC, Andrei Alexandrescu wrote: On 8/19/13 11:14 AM, Dicebot wrote: On Monday, 19 August 2013 at 18:11:34 UTC, Andrei Alexandrescu wrote: I'd call them alias tuples. Because we don't have strict definition of alias too? :) I'm thinking such a tuple may hold everything that one may define an alias to. Normal alias or template alias parameter? ;) Normal alias. Yah, perhaps "template tuples" are more descriptive. Andrei
Re: A Discussion of Tuple Syntax
On 8/19/13 12:54 PM, bearophile wrote:
Meta:
It *could* be an underscore; the only thing is that the underscore is
a valid variable name, so the above expression would actually be
binding two variables, which might surprise someone who was expecting
otherwise. I don't really care all that much, but it's something to
think about.
You can't define a variable more than once in a scope, so this can't be
valid:
void main() {
auto t1 = #(5, "hello", 1.5);
auto (_, _, x) = t1;
auto (_, gr, _) = t1;
}
While ? defines nothing, so this is OK:
void main() {
auto t1 = #(5, "hello", 1.5);
auto (?, ?, x) = t1;
auto (?, gr, ?) = t1;
}
Bye,
bearophile
It's stuff like this that's just useless and gives a bad direction to
the whole discussion. There's hardly anything wrong with auto x = t1[2]
or auto gr = t1[1], but once the bikeshed is up for painting, the
rainbow won't suffice.
Andrei
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 20:36:10 UTC, Andrei Alexandrescu wrote: On 8/19/13 11:14 AM, Dicebot wrote: On Monday, 19 August 2013 at 18:11:34 UTC, Andrei Alexandrescu wrote: I'd call them alias tuples. Because we don't have strict definition of alias too? :) I'm thinking such a tuple may hold everything that one may define an alias to. Normal alias or template alias parameter? ;) Because those two are different :P Former can't take lambda literals. Latter won't accept built-in types like int. But built-in tuple is fine with both. "T..." is a _very_ special thing in D.
Re: A Discussion of Tuple Syntax
On 8/19/13 11:54 AM, Meta wrote: Realistically, Andrei, how amenable are you and Walter to adding tuple literal/packing&unpacking/pattern matching syntax to D, be it Tuple, TypeTuple, whatever? I don't recall either of you commenting much in the two other discussion threads linked. We can discuss this all day, but it what are the actual chances of you agreeing to such a large change in the language? We'd be fools to reject a valuable addition to the language. That being said, there's no broad agreement on what's needed and what's to be added. Furthermore, most discussions are disproportionally focused on syntax (as opposed to semantics) and fall for syntactic cutesies instead of simple and robust library support. That in my experience is a bad omen. Now _that_ being said, if and when a gem comes about, we hope to have the insight to see it. Andrei
Re: Possible solution to template bloat problem?
Just two words: "separate compilation". Any solution that is going to address template problem needs to improve current state with such compilation model, not make it even worse. As an alternative, I have proposed one of two approaches (or both): 1) Stop dumping all symbols into root module supplied from the command line. Emit symbols to object files that match modules they were instantiated from. If symbol has no valid source point (== constraint or CTFE) than don't emit it at all. 2) Create object files in format that allows usage of `ld --gc-sections` (garbage collection of unused symbols upon linking). Don't know if similar thing exists for Windows. Latter should be relatively easy to do but it is not cross-platform and it does not help build systems with tracking rebuild conditions. Former feels like a proper approach and I have been working on it (also @eskimor) for some time. But it is rather hard as relevant code does not seem to track required information at all and probably no one but Walter knows all minor details about its design. To sum it up - I have not been able to produce a pull request that passes the test suite so far (though I have put it on hold for some time, going to return to this).
Re: A Discussion of Tuple Syntax
On 8/19/13 11:14 AM, Dicebot wrote: On Monday, 19 August 2013 at 18:11:34 UTC, Andrei Alexandrescu wrote: I'd call them alias tuples. Because we don't have strict definition of alias too? :) I'm thinking such a tuple may hold everything that one may define an alias to. Andrei
Possible solution to template bloat problem?
With D's honestly awesome metaprogramming features, templates are liable
to be (and in fact are) used a LOT. This leads to the unfortunate
situation of template bloat: every time you instantiate a template, it
adds yet another copy of the templated code into your object file. This
gets worse when you use templated structs/classes, each of which may
define some number of methods, and each instantiation adds yet another
copy of all those methods.
This is doubly bad if these templates are used only during compile-time,
and never referenced during runtime. That's a lot of useless baggage in
the final executable. Plus, it leads to issues like this one:
http://d.puremagic.com/issues/show_bug.cgi?id=10833
While looking at this bug, I got an idea: what if, instead of emitting
template instantiations into the same object file as non-templated code,
the compiler were to emit each instantiation into a separate static
*library*? For instance, if you have code in program.d, then the
compiler would emit non-templated code like main() into program.o, but
all template instantiations get put in, say, libprogram.a. Then during
link time, the compiler runs `ld -oprogram program.o libprogram.a`, and
then the linker will pull in symbols from libprogram.a that are
referenced by program.o.
If we were to set things up so that libprogram.a contains a separate
unit for each instantiated template function, then the linker would
actually pull in only code that is actually referenced at runtime. For
example, say our code looks like this:
struct S(T) {
T x;
T method1(T t) { ... }
T method2(T t) { ... }
T method3(T t) { ... }
}
void main() {
auto sbyte = S!byte();
auto sint = S!int();
auto sfloat = S!float();
sbyte.method1(1);
sint.method2(2);
sfloat.method3(3.0);
}
Then the compiler would put main() in program.o, and *nothing else*. In
program.o, there would be undefined references to S!byte.method1,
S!int.method2, and S!float.method3, but not the actual code. Instead,
when the compiler sees S!byte, S!int, and S!float, it puts all of the
instantiated methods inside libprogram.a as separate units:
libprogram.a:
struct_S_byte_method1.o:
S!byte.method1
struct_S_byte_method2.o:
S!byte.method2
struct_S_byte_method3.o:
S!byte.method3
struct_S_int_method1.o:
S!int.method1
struct_S_int_method2.o:
S!int.method2
struct_S_int_method3.o:
S!int.method3
struct_S_float_method1.o:
S!float.method1
struct_S_float_method2.o:
S!float.method2
struct_S_float_method3.o:
S!float.method3
Since the compiler doesn't know at instantiation time which of these
methods will actually be used, it simply emits all of them and puts them
into the static library.
Then at link-time, the compiler tells the linker to include libprogram.a
when linking program.o. So the linker goes through each undefined
reference, and resolves them by linking in the module in libprogram.a
that defines said reference. So it would link in the code for
S!byte.method1, S!int.method2, and S!float.method3. The other 6
instantiations are not linked into the final executable, because they
are never actually referenced by the runtime code.
So this way, we minimize template bloat to only the code that's actually
used at runtime. If a particular template function instantiation is only
used during CTFE, for example, it would be present in libprogram.a but
won't get linked, because none of the runtime code references it. This
would fix bug 10833.
Is this workable? Is it implementable in DMD?
T
--
Nearly all men can stand adversity, but if you want to test a man's character,
give him power. -- Abraham Lincoln
Why I chose D over Ada and Eiffel
Frontup warning: Some of what I'll write is opinionated, not so much in the sense of being pro or anti (whatever) but rather based on experience and needs. 25+ years ago I started with C. I loved it. But then I had a hacker attitude, considering "raw and tough" the only choice for a real man *g. It took me more than 10 years to recognize (or allow myself to realize) that something was quite unsatisfying about C and that, as much as I understood the necessity of OO and strongly desired io employ it, C++ was not a solution but rather pretty much all disadvantages of C repeated and then a major nightmare added or, excuse my french, a major pain in the a**. Even worse, software development had grown from an obsessive hobby (I was an electronics engineer floating more and more toward software) to a profession and suddenly ugly real world factors like efficiency and productivity entered the equation. While tools like CodeBuilder (a C++ "Delphi") seemed to promise a better life they didn't deliver that much; not because they were bad tool but because of C++. - big jump - By coincidence (or fate?) I found myself confronted with a project demanding extreme reliability and reusability requirements. As much as I tried, C++ just couldn't cut it. One major reason might be interesting (or well known) to some of you: You basically can't rely in third party C++ code. Not meaning to talk bad about anyone but it's my bloody experience. Maybe it's because C++ makes it so hard to actually develop and engineer software (rather than hacking), maybe because C++ attracts guys like my earlier self (the cool C/C++ hacker), whatever the reason may be, that's what I experienced. One obious (or seemingly obvious) solution was Ada. Well, no, it wasn't. Maybe, even probably, if I had to develop low level stuff for embedded stuff but not for a large application. And, that was a killer for me, Ada does not really support easily resizable arrays. To make things worse, while there nowadays is Gnat, a nice modern IDE, there is a major lack of libraries. Falling over the famous Ariane 5 article I looked at Eiffel. I have to confess that I almost feel in love. Eiffel felt just right and Prof. Meyers books convinced me again and again - Yesss, that's the way I'd like to work and develop software. Unfortunately, though, Prof Meyer and ISE (the Eiffel company) made some errors, too, and in a major way. For a starter that whole Eiffel world is pretty much a large beautiful castle ... inmidst a desert. Theoretically there are different compilers, factually, however, ISE's Eiffelstudio is the only one; the others are either brutally outdated or non-conforming or weird niche thingies or eternally in alpha, or a mixture of those. And Eiffelstudio costs north of 5.000 us$. Sure there is a GPL version but that is available only for GPL'ed programs. Next issue: Eiffels documentation is plain lousy. Yes, there are some 5 or so books but those are either purely theoretical or very outdated or both. Yes there is lots of documentation online but most of it basically is luring sales driven "Look how easy it is with Eiffel" stuff. And there is a doxygen like API doc which is pretty worthless for learning how to practically use the language. Furthermore, while Eiffel comes with a lot on board there still is much missing; just as an example there are no SSL sockets which nowadays is a killer. --- jump --- So, I desperately looked for something that would offer at least some major goodies lik DBC and would otherwise at least not stand in the way of proper software engineering. Well, that single feature, Design By Contract, led me toward D. - practically useable modern Arrays? Check. And ranges, too. And very smartly thought up and designed. Great. - Strings? Check Plus UTF, too. Even UTF-8, 16 (a very practical compromise in my minds eye because with 16 bits one can deal with *every* language while still not wasting memory). - DBC? Check And once more the creators of D don't simply address one issue but do it elegantly and, even better, sonsistently by throwing in a nice use cases solution, too. Great! - some kind of reasonable support for modern concurrency? Check And again, not something thrown in that the creators of D religously consider right (like in Eiffel where Meyer basically force feeds his personal religious belief, although the "seperate" solution is elegant). Great! - Some of the major GUI(s)? Check. Well, I couldn't care less about Java (Is t possible to repeat all C problems creating yet another "C++" and invent a whole new slew of burdensome and weird sh*t? Sure, look at java!) but there seems to be a GTK binding. - "defer mechanism"? Check. I'm pondering about some smart defer mechanism since years. Et voilà, D offers the "scope" mechanism. Brilliant, just f*cking brilliant and well made, too! - Genericity? Check Genericity is a must, it's one o
Re: std.serialization: pre-voting review / discussion
On Monday, 19 August 2013 at 19:47:32 UTC, David Nadlinger wrote: Versioning is an integral idea of formats like Protobuf and Thrift. For example, see the "A bit of history" section right on the doc overview page. [1] You might also want to read through the (rather dated) Thrift whitepaper to get an idea about what the design constraints for it were. [2] By the way, to be honest, this is also the main point that makes me feel uneasy about including Orbit in Phobos at this point: Sure, it has been around for some time, but as far as I can tell, not a lot of people are using it right now, and what seems to be entirely missing from the docs is a clear design rationale, outlining its goals and explaining how Orbit compares to well-known existing solutions. It seems to me that a large part of the discussion in this thread can be attributed to that fact, i.e. a lack of understanding/agreement what the module is supposed to be in the first place. David
Re: A Discussion of Tuple Syntax
void main() {
auto t1 = #(5, "hello", 1.5);
auto (_, _, x) = t1;
auto (_, gr, _) = t1;
}
I need to get used to the proposed syntax, sorry:
void main() {
auto t1 = #(5, "hello", 1.5);
auto #(_, _, x) = t1;
auto #(_, gr, _) = t1;
}
Bye,
bearophile
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 19:54:43 UTC, bearophile wrote: ... That too.
Re: A Discussion of Tuple Syntax
Meta:
It *could* be an underscore; the only thing is that the
underscore is a valid variable name, so the above expression
would actually be binding two variables, which might surprise
someone who was expecting otherwise. I don't really care all
that much, but it's something to think about.
You can't define a variable more than once in a scope, so this
can't be valid:
void main() {
auto t1 = #(5, "hello", 1.5);
auto (_, _, x) = t1;
auto (_, gr, _) = t1;
}
While ? defines nothing, so this is OK:
void main() {
auto t1 = #(5, "hello", 1.5);
auto (?, ?, x) = t1;
auto (?, gr, ?) = t1;
}
Bye,
bearophile
Re: Unable to build deimos/libX11 with ldc2
On Monday, 19 August 2013 at 19:25:03 UTC, Adam D. Ruppe wrote: BTW what do you plan to do with the libx11? It's a dependency for Cairo. I want to use Cairo for drawing stuff on the screen. This library is also used by GTK 3 to render all their widgets.Besides that, it supports multiple platforms :). I started my widget toolkit project on github: https://github.com/tyrolite/wkd and I'll make an anouncement on the other thread once I have the code to draw a button. I'll probably get faster there using parts of your code. Thanks !
Re: std.serialization: pre-voting review / discussion
On Monday, 19 August 2013 at 14:47:15 UTC, bsd wrote: I think this versioning idea is more important for protocol buffers, msgpck, thrift like libraries that use a separate IDL schema and IDL-compiled code. std.serialization uses the D code itself to serialize so the version is practically dictated by the user. It may as well be manually handledas long as it throws/returns error and doesn't crash if one tries to deserialize an archive type into a different/modified D type. From memory the Protocol Buffers versioning is to ensure schema generated code and library are compatible. You get compile errors if you try to compile IDL generated code with a newer version of the library. Similarly you get runtime errors if you deserialize data that was serialized with an older version of the library. This is all from memory so I could be wrong... Seems like your memory has indeed faded a bit. ;) Versioning is an integral idea of formats like Protobuf and Thrift. For example, see the "A bit of history" section right on the doc overview page. [1] You might also want to read through the (rather dated) Thrift whitepaper to get an idea about what the design constraints for it were. [2] The main point is that when you have deployed services at the scale Google or Facebook work with, you can't just upgrade all involved parties simultaneously on a schema change. So, having to support multiple versions running along each other is pretty much a given, and the best way to deal with that is to build it right into your protocols. David [1] https://developers.google.com/protocol-buffers/docs/overview [2] http://thrift.apache.org/static/files/thrift-20070401.pdf
Re: Unable to build deimos/libX11 with ldc2
BTW what do you plan to do with the libx11? You might find my simpledisplay.d (also depends on color.d) interesting from my miscellaneous github: https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff It provides a class called SimpleWindow that supports basic drawing and some input stuff (input is in the middle of an overhaul right now, I'm fixing a lot of bugs and will be posting that new code online in a few days, but even right now it still works for checking ascii keys at least), on top of Xlib, with equivalent code for Windows in there too so your same program can compile cross platform. Though I've never tried to compile it on ldc either, I did my own xlib bindings (included in the same simpledisplay.d file) so it might work; surely won't have the *same* bugs at least.
Re: A Discussion of Tuple Syntax
On 08/19/2013 07:44 PM, H. S. Teoh wrote: Well, OK, whatever they're supposed to be called. Compiler-tuples, or expression tuples, or whatever. See, part of the problem is that they just don't have any good name that correctly conveys what they are. They are simply template argument lists. (http://wiki.dlang.org/The_D_Programming_Language/Seq)
Re: Unable to build deimos/libX11 with ldc2
Oh, sorry for using the wrong forum section. I used the dmd compiler and the build went fine. Is pretty weird though because ldc2 is the default compiler used to build libX11. I filed an issue report for deimos/libX11 on their project page.
Re: std.serialization: pre-voting review / discussion
19-Aug-2013 22:05, Johannes Pfau пишет: Am Mon, 19 Aug 2013 16:21:44 +0200 schrieb "Tyler Jameson Little" : Another point is that "serialize" in the above example could be renamed to "put". This way Serializer would itself be an OutputRange which allows stuff like [1,2,3,4,5].stride(2).take(2).copy(archive); +1 I totally expect serializer to be a sink. Then serialize could also accept InputRanges to allow this: archive.serialize([1,2,3,4,5].stride(2).take(2)); However, this use case is already covered by using copy so it would just be for convenience. -- Dmitry Olshansky
Re: A Discussion of Tuple Syntax
Realistically, Andrei, how amenable are you and Walter to adding tuple literal/packing&unpacking/pattern matching syntax to D, be it Tuple, TypeTuple, whatever? I don't recall either of you commenting much in the two other discussion threads linked. We can discuss this all day, but it what are the actual chances of you agreeing to such a large change in the language?
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 18:19:11 UTC, bearophile wrote: The ? of regexes is inside strings, so I think it causes no problems. And I think it doesn't clash with the ternary operator because before the ? wildcard you put a comma, a semicolon or a #(. I was primarily addressing the fact that there aren't many _meanings_ attached to the same character. This was brought up before when someone talked about using an asterisk, but it was pointed out that it would be a bad choice because it's already commonly seen in multiplication, pointers, and exponentiation (**). If anything, I'm inclined to think the regex heritage of the question mark improves its case. -Wyatt
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 16:53:06 UTC, Wyatt wrote:
To be clear, I'm not talking about braces, {}; I'm talking
about parentheses, (). I read over that whole DIP32 thread a
couple times, and didn't see any rationale offered for why the
likely "cleanest" version "can't be used". It wasn't even
brought up (unless I've missed something subtle). In the
second thread, linked in the OP here, they were glossed over
again. Now, I fully believe there's a very good reason that's
been written somewhere, but I _would_ like to know what that
is, preferably documented somewhere less ephemeral and
difficult to search than the newsgroup (such as in DIP32). The
closest I've seen so far is the pull request where Walter and
Andrei expressed that it should be considered further.
I could very well be wrong, but I would bet that one of the
reasons is that (a, b, c) expressions already have well-defined
semantics in D (as well as (2, "a", func()). Example:
void main()
{
import std.stdio;
//Prints "a"
writeln((true, false, "a"));
}
Making this a tuple literal would be a change in semantics, which
I don't think would go over well and would break code. Another
example:
void main()
{
int a, b;
(a, b) = (3, 4);
assert(a == 0 && b == 4);
}
Of course, for the second case, Kenji's proposed syntax used
"auto (a, b) = ...", which would disambiguate it, but it could
confuse people as to whether the first syntax is somehow related
to the second.
The octothorpe _is_ much better than the t simply in terms of
readability, though, even more than q{} or t{}, I have concerns
about its ability to be found with an ordinary search engine by
an ordinary user. Have you tried looking for documentation on
weird operators with a search engine lately? They don't
exactly take to it well. :/ (cf. Perl's <=>)
I'm not sure how much of a problem that would be. There's only
one other syntactic form that uses # in D, but you're right, it
may cause some difficulty trying to search "d programming #".
Addressing the other suggestion I saw that cropped up, I
personally find the two-character "bananas" to be impressively
ugly. I considered suggesting some permutation on that same
idea, but after toying with a few examples I find it ends up
looking awful and I think it's honestly annoying to type them
in any form. I even don't like how the unicode version of that
one looks; for doubling up, I think ⟦ ⟧ or ⟪ ⟫ or are easier on
the eyes.
My browser can't even display the second set of characters. D
seems to have generally shied away from using any unicode
operators (for a good reason. Who the hell has Σ on their
keyboard?)
I feel weird admitting this, but if we can't use some manner of
bare brace, I think I'd rather have tup(), tup[], tup{} (or
even tuple() et al) as a prefix over any single character.
It's not terrible, but it's rather wordy, especially if tuples
begin to be used a lot in code.
Can't make it a single underscore? Question mark works best
then, IMO. It isn't as burdened with meanings elsewhere (sure
there's ternary and possibly-match in regex, but...have I
forgotten something?)
It *could* be an underscore; the only thing is that the
underscore is a valid variable name, so the above expression
would actually be binding two variables, which might surprise
someone who was expecting otherwise. I don't really care all that
much, but it's something to think about.
#(a, ...) looks like to me like it would make a 2-tuple
containing a and a tuple of "everything else", because of the
ellipsis' use in templated code. I think this is a little
unclear, so instead I'd prefer #(a, ? ...) (or whatever ends up
used for the discard character) to make it explicit.
To be clear, what I have in mind is that this would be "a, plus
(none/one?) or more things that can either be elements or nested
tuples". Then, in a construction such as #(head, rest...), rest
would be exactly as you describe: a tuple consisting of
everything after head. The semantics could get tricky, maybe this
needs more thought.
As a bonus, explicit discard means a simple comma omission is
less likely to completely change the meaning of the statement.
Compare:
#(a, b, ...) //bind the first two elements, discard the rest.
#(a, b ...)//bind the first element to a and everything
else to b
#(a, b, ? ...) //same as the first
#(a, b ? ...) //syntax error
Granted, there's this case:
#(a, ?, ...)
...but that seems like it would be less common just based on
how people conventionally order their data structures.
That's true. Something to think about. Maybe combine the question
mark and ellipsis like so:
#(a, b, ?..)
Thought: Is there sufficient worth in having different tokens
for discarding a single element vs. a range? e.g.
#(a, ?, c, * ...) //bind first and third elements; discard the
rest
// I'm not attached to the asterisk there.
// +, #
Re: A Discussion of Tuple Syntax
On Mon, Aug 19, 2013 at 08:10:38PM +0200, Dicebot wrote: > On Monday, 19 August 2013 at 17:57:45 UTC, Meta wrote: > >As far as I can tell, when everyone talks about tuple syntax, they > >are talking about run-time tuples. That's definitely what I'm > >talking about whenever I mention tuple syntax, as I don't think it > >would be a good thing to use it for both run-time and compile-time > >tuples (and I don't really consider the latter tuples). > > No. I speak exclusively about native syntax for compile-time tuples > and stand by the point that run-time tuples are mostly fine as-is > and should not be touched at all. Case in point. :) So we're actually talking at cross purposes here. Bearophile & Meta et al want native syntax for *runtime* tuples (i.e. std.typecons.Tuple -- sorry for the mixup with std.range in my earlier posts), but you're talking about native syntax for alias tuples (aka TypeTuples). Two completely different things. I agree that we shouldn't be making built-in syntax for a library type. If anything, any dedicated syntax should be reserved for alias tuples (aka std.typetuple.Typetuple). Or, at the very least, rename TypeTuple to AliasTuple. Conflating these two concepts has led to endless confusion, which is why I insisted on addressing this issue before we even begin to talk about syntax. Otherwise we're going nowhere. T -- Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry
Experience report: teaching D at a summer course at University of Minnesota
http://www.reddit.com/r/programming/comments/1ko94o/experience_report_teaching_d_at_a_summer_course/
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 18:19:11 UTC, bearophile wrote:
Mine was an idea, but if it turns out to be a bad idea, then
let's ignore it.
I was initially completely opposed against it but now that I have
realized built-in ones do some run-time magic too, it does not
sound _that_ crazy anymore.
Seriously, if current std.typecons.Tuple is implemented in terms
if built-in tuple, than it sounds like only think built-in ones
are lacking is ABI. Define it and using one single tuple syntax /
implementation for everything becomes real.
I mean:
import std.typecons;
import std.typetuple;
void main()
{
alias TT = TypeTuple!(int, string);
// moar confusion for gods of confusion!
// what is the difference between twoVars1 and twoVars2
other than latter is wrapped into struct and has ABI?
TT twoVars1;
Tuple!(int, string) twoVars2;
}
Re: Unable to build deimos/libX11 with ldc2
On Monday, 19 August 2013 at 18:05:41 UTC, Paul Z. Barsan wrote: deimos/X11/Xlibint.d(895): Error: Function type does not match previously declared function with the same mangled name: Data Without having looked at the libX11 sources at all, the error message implies that there are multiple "extern(C)" function declarations named Data that have different types. This is likely an issue with the libX11 bindings and should be fixed there. DMD doesn't care about that, but in LDC we would have to specifically work around a related LLVM "restriction" to be able to accept that code. Oh, and in the future, you might want to post similar questions to digitalmars.D.learn. David
Re: A Discussion of Tuple Syntax
Wyatt:
The octothorpe _is_ much better than the t simply in terms of
readability, though, even more than q{} or t{}, I have concerns
about its ability to be found with an ordinary search engine by
an ordinary user. Have you tried looking for documentation on
weird operators with a search engine lately? They don't
exactly take to it well. :/ (cf. Perl's <=>)
I think none of the suggested tuple syntaxes are well searchable
on Google, but the "tuple()" syntax.
But in the Haskell world the Hoogle direct&reverse search engine
supports symbols too (but it's mostly used to search for
functions given their signature, I think so far this is something
not present in the D world):
http://www.haskell.org/hoogle/?hoogle=%3D%3E
I even don't like how the unicode version of that one looks;
It was just an idea, to show what I meant by representing the
bananas with Unicode glyphs. The actual choice of glyphs is not
an urgent choice :-) The idea comes from the now dead Fortress
language.
I feel weird admitting this, but if we can't use some manner of
bare brace, I think I'd rather have tup(), tup[], tup{} (or
even tuple() et al) as a prefix over any single character.
At the moment I prefer #() syntax, with ? for single wildcards.
It's better than tup{} or t{} because the # symbol pops out more
visually. tuple() syntax is long, but it's readable, and perhaps
partially backwards compatible.
Can't make it a single underscore? Question mark works best
then, IMO. It isn't as burdened with meanings elsewhere (sure
there's ternary and possibly-match in regex, but...have I
forgotten something?)
The ? of regexes is inside strings, so I think it causes no
problems. And I think it doesn't clash with the ternary operator
because before the ? wildcard you put a comma, a semicolon or a
#(.
Assuming the "..." syntax for unpacking, it would be useful to
name the captured tail. For example, you could unpack #(1, 3,
#(4, 6)) into #(a, b, x...), where a = 1, b = 3, x = #(4, 6).
Similarly, #(head, rest...) results in head = 1, rest = #(2,
#(4, 6)). I think this would be very useful.
In Haskell there is also a way to give a name to the whole tuple
and names to its parts:
Prelude> let t1 = (10, 20)
Prelude> let a@(b, c) = t1
Prelude> a
(10,20)
Prelude> b
10
Prelude> c
20
-
Meta:
Bearophile has mentioned a couple times that we could use the
tuple syntax for both, and bring about a unification of these
two tuple types. I don't like this, as they're both very
different entities, and don't really have any relation to
each-other whatsoever.
Mine was an idea, but if it turns out to be a bad idea, then
let's ignore it.
Bye,
bearophile
Re: Ideas for a brand new widget toolkit
On Friday, 16 August 2013 at 12:36:39 UTC, Wyatt wrote: On Thursday, 15 August 2013 at 18:35:22 UTC, Joakim wrote: I've only done X11 forwarding over ssh, both WAN and LAN, it was incredibly laggy in both cases. As Andrei and I have pointed out, NX does a much better job of things. If nothing else, read the explanation of how it works-- there are perceptual subtleties to this that aren't apparent at first glance: http://www.nomachine.com/documents/NX-XProtocolCompression.php I don't much care if X11 can be made faster. Unless you plan on bundling an X server with your Windows app, it's not an option for a cross-platform GUI. In any case, if X11 is in fact similar to the approach I laid out, I obviously think that approach can be done speedily, though X11 probably bites off too much whereas I carefully constrained the problem for my Crack client.
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 18:11:34 UTC, Andrei Alexandrescu wrote: I'd call them alias tuples. Because we don't have strict definition of alias too? :) Actually, I have forgot again that built-in tuples are not always compile-time. They can be used to declare run-time entities with tuple syntax too, that was exactly what was abused in std.typecons.Tuple implementation. As I have already said, it is hard to name something that does not have clear semantics and is essentially just random collection of behavior.
Re: A Discussion of Tuple Syntax
On 8/19/13 10:54 AM, Dicebot wrote: On Monday, 19 August 2013 at 17:45:44 UTC, H. S. Teoh wrote: On Mon, Aug 19, 2013 at 07:34:38PM +0200, Dicebot wrote: On Monday, 19 August 2013 at 17:22:26 UTC, H. S. Teoh wrote: >What I'd like to know, is how all of these proposals address >the >fundamental differences between "symbol tuples" (compile-time >construct) Those are not symbol tuples. For example, `int` is not a symbol. http://dlang.org/template.html#Symbol - only things that have identifiers and template instances are symbols. Well, OK, whatever they're supposed to be called. Compiler-tuples, or expression tuples, or whatever. Well, technically they are compile-time tuples of stuff. I'd call them alias tuples. Andrei
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 17:57:45 UTC, Meta wrote: As far as I can tell, when everyone talks about tuple syntax, they are talking about run-time tuples. That's definitely what I'm talking about whenever I mention tuple syntax, as I don't think it would be a good thing to use it for both run-time and compile-time tuples (and I don't really consider the latter tuples). No. I speak exclusively about native syntax for compile-time tuples and stand by the point that run-time tuples are mostly fine as-is and should not be touched at all.
