date:20130820


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: 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 stdio.h, 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: 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: Why I chose D over Ada and Eiffel


On 2013-08-19 23:17, H. S. Teoh wrote:


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*).


Oh, what I wish that was true. We're still struggling with encoding 
problems at work due to browsers and third party services and tools not 
being able to handle Unicode.


--
/Jacob Carlborg

Re: Why I chose D over Ada and Eiffel


On 2013-08-20 00:14, Walter Bright wrote:


Note the holding back of std.serialization until it has full support for
ranges.


I guess we won't see any std.serialization then. It cannot fully support 
ranges until the backend does, in this case std.xml.


--
/Jacob Carlborg

Re: Why I chose D over Ada and Eiffel


On 2013-08-19 22:18, Ramon wrote:


An added major plus is D's bluntly straight interface to C. And a vital
one, too, because let's face it, not being one of the major players in
languages basically means to either not have a whole lot of major and
important libraries or else to (usually painfully) bind them. D offers
an excellent solution and gives me the peace of mind to not paranoically
care about *every* important library coming with it.


You can use this tool to automatically generate bindings to C libraries:

https://github.com/jacob-carlborg/dstep


Criticism:

OK, I'm biased and spoiled by Eiffel but not having multiple inheritance
is a major minus with me. D seems to compensate quite nicely by
supporting interfaces. But: I'd like more documentation on that. Go and
read at wikipedia just doesn't cut it. Please, kindly, work on some
extensive documentation on that.


You can get quite close with interfaces and templates:

interface Foo
{
void foo ();
}

template FooTrait
{
void foo (); { writeln(foo); }
}

class A : Foo
{
mixin FooTrait;
}

class B
{
void b () { }
}

class Bar : B, Foo
{
mixin FooTrait;
}

--
/Jacob Carlborg

Re: Ideas for a brand new widget toolkit


On 2013-08-19 23:01, Ramon wrote:


- 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.


If native controls are used then the first step is make sure we have 
proper and easy to use bindings to these. For example, it's a PITA to 
access Objective-C frameworks (needed for Mac OS X) form D. So we need this:


http://michelf.ca/projects/d-objc/syntax/

Most up to date code: https://github.com/jacob-carlborg/dmd/tree/d-objc

--
/Jacob Carlborg

Re: Possible solution to template bloat problem?


On 2013-08-19 22:22, H. S. Teoh wrote:


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:


Doesn't the compiler already do something like that with the -lib flag?

--
/Jacob Carlborg

Re: Why I chose D over Ada and Eiffel


On 8/20/2013 12:02 AM, Jacob Carlborg wrote:

On 2013-08-20 00:14, Walter Bright wrote:


Note the holding back of std.serialization until it has full support for
ranges.


I guess we won't see any std.serialization then. It cannot fully support ranges
until the backend does, in this case std.xml.


Why not?

Re: OT; Will MS kill .NET ?

2013-08-20 Thread Paulo Pinto


On Tuesday, 20 August 2013 at 01:28:38 UTC, 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


Usually these articles are written by people without proper 
Microsoft ecosystem experience.


I do consulting both on Java and .NET worlds mainly.

.NET is still going strong, Microsoft has done quite a few 
updates in the form of .NET 4.5 recently and most talks at BUILD 
2013 were about .NET.


What has happened was shift to the native runtime WinRT (which is 
basically COM) as the common platform. Althought only for Window 
Apps, not desktop based.


.NET is fully supported and no different than MSVCRT for C(++), 
or phobos for D.


--
Paulo

Re: OT; Will MS kill .NET ?

2013-08-20 Thread Paulo Pinto


On Tuesday, 20 August 2013 at 02:20:38 UTC, Luís Marques wrote:
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



With the failure that Longhorn and Vista were, the .NET political 
camp inside Microsoft lost power to the native guys.


I bet this is what was behind the WinRT decision, because the 
original .NET design documents for .NET were actually based in 
COM as well.


http://blogs.msdn.com/b/dsyme/archive/2012/07/05/more-c-net-generics-history-the-msr-white-paper-from-mid-1999.aspx

Even if Microsoft decides to go fully native, then just have to 
change the C#/VB.NET/F# compilers to generate fully native 
binaries instead of MSIL.


.NET is just a language runtime. Developers should not confuse 
languages with implementations.


--
Paulo

[dox] C++ Interfaces

2013-08-20 Thread Atash


This link: http://dlang.org/CPP-Interfaces

Is made on this page: http://dlang.org/interface.html

And I *think* (not sure) that since whatever it was originally 
pointing to has disappeared, it should probably end up pointing 
here:


http://dlang.org/cpp_interface.html

Maybe add an anchor to about halfway down the page, so it'd look 
more like:


http://dlang.org/cpp_interface.html#extern-CPP-interfaces



That all said...

Is my assessment correct/proper?

If so, in the great words of my esteemed predecessors from the 
vast wilds of newbie-dom... What do?

Re: std.serialization: pre-voting review / discussion


On 8/12/2013 6:27 AM, Dicebot wrote:

Documentation:
https://dl.dropboxusercontent.com/u/18386187/docs/std.serialization/index.html


Thank you, Jacob. It looks like you've put a lot of nice work into this.

I've perused the documentation, and all I can think of is What's a cubit?

http://www.youtube.com/watch?v=so9o3_daDZw

I.e. there are 9 documentation pages of details. There's no obvious place to 
start, no overview, no explanation of what serialization is for and why I might 
want to use it and what's great about this implementation. At least none that I 
could find. Also needs some non-trivial canonical example code.


Something that answers who what where when why and how would be immensely 
useful.



Some nits:

https://dl.dropboxusercontent.com/u/18386187/docs/std.serialization/std_serialization_serializationexception.html

Something went horribly wrong here:

Parameters:
Exception exception the exception exception to wrap


https://dl.dropboxusercontent.com/u/18386187/docs/std.serialization/std_serialization_registerwrapper.html

Lacks an illuminating example.

https://dl.dropboxusercontent.com/u/18386187/docs/std.serialization/std_serialization_serializer.html

When would I use a struct Array or a struct Slice?

https://dl.dropboxusercontent.com/u/18386187/docs/std.serialization/std_serialization_attribute.html

struct attribute should be capitalized. When would I use an attribute? Does this 
have anything to do with User Defined Attributes? Need a canonical example.


https://dl.dropboxusercontent.com/u/18386187/docs/std.serialization/std_serialization_archives_archive.html

Aren't interfaces already abstract? I.e. abstract is redundant. The 
documentation defines an archive more or less as an archive. I still don't know 
what an archive is. (E.g. a zip file is an archive - can this create zip files?)

Re: GPGPU and D

2013-08-20 Thread Atash


On Sunday, 18 August 2013 at 19:02:50 UTC, luminousone wrote:

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.


Github seems fine to me, my coding skills are likely more 
limited then Atash or John; I am currently working as a student 
programmer at Utah's Weber State University while also 
attending as a part time student, I am currently working on 
finishing the last couple credit hours of the assoc degree in 
CS, I would like to work towards a higher level degree or even 
eventually a Phd in CS.


I will help in whatever way I can however.


You give me too much credit. :-P

I'm yet another student, technically in biomedical engineering 
but with a very computer-science-y mind. My experience with 
OpenCL has been limited to a few stints into some matrix 
operations and implementing that sort I linked earlier for the 
sake of a max-reduction operation found in a GPGPU implementation 
of support-vector machine classifiers. Frankly, I *hate* *hate* 
*hate* boilerplate, so I paradoxically spend all my time trying 
to get it out of the way so I never need to write it again. 
Decent for code-prettiness, horrid for deadlines. That said...


I'm hesitant to start anything new until I've cleared my plate of 
at least one of my current projects, so while I am very 
interested in jumping on this, I'm going to have to pass on doing 
anything serious with it for the next several weeks. -.-'

Re: std.serialization: pre-voting review / discussion


On 8/18/2013 9:33 AM, David Nadlinger wrote:

Having a system that regularly, automatically runs the test suites of several
larger, well-known D projects with the results being readily available to the
DMD/druntime/Phobos teams would certainly help. But it's also not ideal, since
if a project starts to fail, the exact nature of the issue (regression in DMD or
bug in the project, and if the former, a minimal test case) can often be hard to
track down for somebody not already familiar with the code base.


That's exactly the problem. If these large projects are incorporated into the 
autotester, who is going to isolate/fix problems arising with them?


The test suite is designed to be a collection of already-isolated issues, so 
understanding what went wrong shouldn't be too difficult. Note that already it 
is noticeably much harder to debug a phobos unit test gone awry than the other 
tests. A full blown project that nobody understands would fare far worse.


(And the other problem, of course, is the test suite is designed to be runnable 
fairly quickly. Compiling some other large project and running its test suite 
can make the autotester much less useful when the turnaround time increases.)


Putting large projects into the autotester has the implication that development 
and support of those projects has been ceded to the core dev team, i.e. who is 
responsible for it has been badly blurred.

Re: std.serialization: pre-voting review / discussion

2013-08-20 Thread ilya-stromberg

On Tuesday, 20 August 2013 at 03:42:48 UTC, Tyler Jameson Little 
wrote:

On Monday, 19 August 2013 at 18:06:00 UTC, Johannes Pfau wrote:
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.


No, you are WRONG. InputRange is MORE flexible: it can be lazy or 
eager. OutputRange is only eager. As we know, lazy ranges is 
required if it's possible:


On Sunday, 18 August 2013 at 18:26:55 UTC, Dicebot wrote:
So as a review manager, I think voting should be delayed until 
API is ready to address lazy range-based work model. No actual 
implementation is required but


1) it should be possible to do it later without breaking user 
code
2) library should not make an assumption about implementation 
being lazy or eager


We can use InputRange like this:

import std.file;
auto archive = new Archive()
Serializer(archive).serialize(object);
//Archive implements InputRange for ubyte[]
write(file, archive);

Another benefit: we can process InputRange. For example, if we 
have

ZipRange zip(InputRange)
function, it's easy to compress data:
write(file, zip(archive));

Another example: we would like to change output xml file and 
filter some data (because we already have it). Or we would like 
to transform output xml to the html web page. No problems:


XmlRange transformXml(InputRange);
write(file, transformXml(archive));

Ideas?

Re: new operator chaining (D vs Java)

2013-08-20 Thread deadalnix


On Tuesday, 20 August 2013 at 02:25:35 UTC, Luís Marques wrote:
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)


That isn't coincidence ;) BTW, it is supposed to work by spec for 
ages.

Re: A Discussion of Tuple Syntax

2013-08-20 Thread Mr. Anonymous


On Monday, 19 August 2013 at 18:43:37 UTC, Meta wrote:

On Monday, 19 August 2013 at 16:53:06 UTC, Wyatt wrote:
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.


Why not just leave an empty space, like php does:

$info = array('coffee', 'brown', 'caffeine');
// let's skip to only the third one
list( , , $power) = $info;
echo I need $power!\n;

http://php.net/manual/en/function.list.php

Re: Why I chose D over Ada and Eiffel

2013-08-20 Thread Chris


On Tuesday, 20 August 2013 at 07:08:08 UTC, Jacob Carlborg wrote:


You can use this tool to automatically generate bindings to C 
libraries:


https://github.com/jacob-carlborg/dstep



Great stuff, Jacob! Congratulations.

One thing that is usually not mentioned in articles about D is 
that you don't need an IDE to develop in D. This was, if I 
remember it correctly, one of the design goals.

Re: Possible solution to template bloat problem?

2013-08-20 Thread Daniel Murphy

H. S. Teoh hst...@quickfur.ath.cx wrote in message 
news:mailman.213.1376962388.1719.digitalmar...@puremagic.com...

 [...]
 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 executable form to permit many optimizations that could
 in theory be performed by the linker, requiring instead hacks like weak
 symbols, unused section GC, etc..

 On the more mundane side, we need better algorithms for improving linker
 performance. Current symbol resolution algorithms don't scale very well
 when your object files are large or have large numbers of symbols.
 Surely there are ways of improving the asymptotic complexity of these
 things!



Check out llvm's lld.  Their choice of language sucks, but they do appear to 
be trying to rethink the whole mess.

Re: Why I chose D over Ada and Eiffel


On Tuesday, 20 August 2013 at 00:08:31 UTC, Ramon wrote:
Needing a min(), say for strings, ints and floats in a program 
one shouldn't end up with 3 times code but with code dealing 
with e.g. any scalar or even anything comparable.


No matter how you cut it, you have to pay for dealing with 
different types in one function. Either by code-bloat or 
indirection. The asm for ints, floats, reals etc. are all 
different and require different code.


See here: 
http://forum.dlang.org/post/mailman.213.1376962388.1719.digitalmar...@puremagic.com

Re: A Discussion of Tuple Syntax

2013-08-20 Thread eles


On Friday, 16 August 2013 at 21:07:52 UTC, Meta wrote:
A good, comprehensive design has the potential to make tuples 
easy to use and understand, and hopefully clear up the 
unpleasant situation we have currently. A summary of what has 
been discussed so far:


- (a, b) is the prettiest syntax, and it also completely 
infeasible


- {a, b} is not as pretty, but it's not that bad of an 
alternative (though it may still have issues as well)


- #(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


What about:

!!(a, b)

? Yes, is long, but is type-able quite fast.

Alternative would be:

??(a, b)

.

Re: A Discussion of Tuple Syntax

2013-08-20 Thread Mr. Anonymous


On Tuesday, 20 August 2013 at 10:38:30 UTC, eles wrote:

On Friday, 16 August 2013 at 21:07:52 UTC, Meta wrote:
A good, comprehensive design has the potential to make tuples 
easy to use and understand, and hopefully clear up the 
unpleasant situation we have currently. A summary of what has 
been discussed so far:


- (a, b) is the prettiest syntax, and it also completely 
infeasible


- {a, b} is not as pretty, but it's not that bad of an 
alternative (though it may still have issues as well)


- #(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


What about:

!!(a, b)

? Yes, is long, but is type-able quite fast.

Alternative would be:

??(a, b)

.


It's not only long, but also ugly (IMO of course).

Re: When compiling multiple source files


On Tuesday, 20 August 2013 at 06:50:12 UTC, Jacob Carlborg wrote:

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.


Hah, ram problems running the unittests. This old laptop 
can't even summon enough ram to compile phobos at all!

Re: Why I chose D over Ada and Eiffel


On Tuesday, 20 August 2013 at 07:21:43 UTC, Walter Bright wrote:

On 8/20/2013 12:02 AM, Jacob Carlborg wrote:

On 2013-08-20 00:14, Walter Bright wrote:

Note the holding back of std.serialization until it has full 
support for

ranges.


I guess we won't see any std.serialization then. It cannot 
fully support ranges

until the backend does, in this case std.xml.


Why not?


As far as I understand the problem, current std.xml 
implementation does not allow to implement lazy range-based 
archiver in terms of Phobos.


Not however, that I have not delayed voting until 
std.serialization gets full support of ranges - only until its 
API gets support for ranges such that implementation can be later 
added in a non-breaking way, for example, with new archivers.


There is some small discussion on this topic. Unfortunately I had 
not take the time to study source deep enough to state what 
reasonable requirements can be here (ones that won't require 
Jacob to re-implelement half of the package) but I am definitely 
going to.

Re: std.serialization: pre-voting review / discussion

2013-08-20 Thread Johannes Pfau

Am Tue, 20 Aug 2013 10:40:57 +0200
schrieb ilya-stromberg ilya-stromberg-2...@yandex.ru:

 On Tuesday, 20 August 2013 at 03:42:48 UTC, Tyler Jameson Little 
 wrote:
  On Monday, 19 August 2013 at 18:06:00 UTC, Johannes Pfau wrote:
  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.
 
 No, you are WRONG. InputRange is MORE flexible: it can be lazy or 
 eager. OutputRange is only eager. As we know, lazy ranges is 
 required if it's possible:
 
 On Sunday, 18 August 2013 at 18:26:55 UTC, Dicebot wrote:
  So as a review manager, I think voting should be delayed until 
  API is ready to address lazy range-based work model. No actual 
  implementation is required but
 
  1) it should be possible to do it later without breaking user 
  code
  2) library should not make an assumption about implementation 
  being lazy or eager
 
 We can use InputRange like this:
 
 import std.file;
 auto archive = new Archive()
 Serializer(archive).serialize(object);
 //Archive implements InputRange for ubyte[]
 write(file, archive);

Yes, InputRange is more flexible, but it's also more difficult to
implement and less efficient:
What happens between the 'serialize' and the 'write' call? Archive
has to cache the data, either the original object or the final
produced data in an ubyte[] buffer. 

 
 Another benefit: we can process InputRange. For example, if we 
 have
 ZipRange zip(InputRange)
 function, it's easy to compress data:
 write(file, zip(archive));
 
 Another example: we would like to change output xml file and 
 filter some data (because we already have it). Or we would like 
 to transform output xml to the html web page. No problems:

Filtering is easier with an InputRange. Zip-Streams on the other
hand should be OutputRanges and therefore work fine with both
approaches.

 XmlRange transformXml(InputRange);
 write(file, transformXml(archive));
 
 Ideas?

The question is are there real-world examples where this is useful. You
have to gauge the utility of this approach against it's more complicated
and less efficient implementation.

Re: A Discussion of Tuple Syntax


On Tuesday, 20 August 2013 at 03:33:51 UTC, Kenji Hara wrote:


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



There are various other characters that could be substituted for #
e.g.
(1, string)

http://forum.dlang.org/post/cokiixatvjmngggpb...@forum.dlang.org

Re: A Discussion of Tuple Syntax


On 2013-08-20 05:33, Kenji Hara wrote:


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)


If I recall correctly some ABI's passes small structs in registers, at 
least I think it does on Mac OS X.



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.


It depends on how it's lexed. If the compiler lexes #line as a single 
token I cannot see how it will be a problem. Then the # token would 
mean tuple literal.


--
/Jacob Carlborg

Re: When compiling multiple source files


On 2013-08-20 12:45, John Colvin wrote:


Hah, ram problems running the unittests. This old laptop can't even
summon enough ram to compile phobos at all!


Haha, that's bad. How much RAM do you have?

--
/Jacob Carlborg

Re: new operator chaining (D vs Java)


On 2013-08-20 11:02, deadalnix wrote:

On Tuesday, 20 August 2013 at 02:25:35 UTC, Luís Marques wrote:

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)


That isn't coincidence ;) BTW, it is supposed to work by spec for ages.


I have been adding parentheses in DWT for ages :(. At least it's good 
that it's finally changed.


--
/Jacob Carlborg

Re: A Discussion of Tuple Syntax


On Tuesday, 20 August 2013 at 03:33:51 UTC, Kenji Hara wrote:
Sorry I cannot reply to each thread comments quickly, so I 
discharge my

opinions at once.


One thing that I think does not get deserved attention is that 
built-in expression tuple are not limited to compile-time values. 
Lets consider this simple example:


void foo(T...)(T args)
{
pragma(msg, args);
pragma(msg, typeof(args));
}

void main()
{
int a, b;
foo(a, b);
}


---

/d147/f686.d(3): Error: variable _param_0 cannot be read at 
compile time /d147/f686.d(3): Error: variable _param_1 cannot be 
read at compile time tuple(_param_0, _param_1) (int, int)


---

What we have here are two completely different _built-in_ tuple 
types. T is pure template arguments list and is pretty much 
equal TypeTuple!(int, int). But what is args? It uses the very 
same built-in tuple syntax but it is much closer to 
std.typecons.Tuple in its behavior (actually, latter is 
implemented in terms of it as I was pointed out) - it is an 
entity that provides abstraction of top of group of run-time 
values. It does not have any binary structure on its own (built 
on top of existing values) but observable semantic are very 
run-time'ish.


What bothers me is the question can we clean this up and bring 
those two worlds together, even at cost of minor breakage?. I am 
not speaking about literals here or unpacking or whatever. I am 
speaking about re-defining semantics so that struct-based Tuple 
and built-in syntax sugar in form of run-time expression tuple 
both get merged into one built-in construct which can be used in 
wider variety of places.


At least right now I can't find any technical objections why 
expression tuple can't use std.typecons.Tuple ABI when returned 
from function but still be automatically expanded when passed 
into functions. Kenji, what is your your opinion about complexity 
to implement something like that in DMD?

Re: When compiling multiple source files


On Tuesday, 20 August 2013 at 11:08:51 UTC, Jacob Carlborg wrote:

On 2013-08-20 12:45, John Colvin wrote:

Hah, ram problems running the unittests. This old laptop 
can't even

summon enough ram to compile phobos at all!


Haha, that's bad. How much RAM do you have?


Only 2GB

It can work... but I have to close everything else running first, 
otherwise it locks everything up and then crashes out complaining 
about not having enough memory to fork.

Re: OT; Will MS kill .NET ?

2013-08-20 Thread Luís.Marques


On Tuesday, 20 August 2013 at 07:45:28 UTC, Paulo Pinto wrote:
With the failure that Longhorn and Vista were, the .NET 
political camp inside Microsoft lost power to the native guys.


I bet this is what was behind the WinRT decision, because the 
original .NET design documents for .NET were actually based in 
COM as well.


Interesting!

Even if Microsoft decides to go fully native, then just have to 
change the C#/VB.NET/F# compilers to generate fully native 
binaries instead of MSIL.


.NET is just a language runtime. Developers should not confuse 
languages with implementations.


I don't quite agree with this. Imagine if I said they just have 
to change their Javascript compilers to produce native code. 
It's clear that the semantics of the JS language do not map well 
enough to the x86 semantics for us to consider the produced x86 
code to be fully native. It would be x86 code, but you wouldn't 
be able to do systems programming, like in C++ or D. To a lesser 
extent the same is true with, say, C#. The design of the language 
makes it less native to a x86 CPU than C++.

Re: A Discussion of Tuple Syntax

2013-08-20 Thread Wyatt


On Tuesday, 20 August 2013 at 09:02:29 UTC, Mr. Anonymous wrote:


Why not just leave an empty space, like php does:

$info = array('coffee', 'brown', 'caffeine');
// let's skip to only the third one
list( , , $power) = $info;
echo I need $power!\n;


Bad idea.  It's a visual thing--  quick! How wide is this tuple!?:
#(,frontvar,)

How long did it take you to be SURE that it's a seven-tuple?  You 
probably aren't even equipped to measure that so don't worry 
about answering, but I'm guessing you start to appreciate why 
it's a fairly inhumane solution (how drearily typical for PHP).


Ah, but what if it was supposed to be #(,front,var,)?  Does 
that change your result, now that you're taking the sixth element 
rather than the seventh?  All you did was forget a comma!  By 
contrast:
#(?,front,?,?,?,var,?,?) //at least gives us a better chance of 
parsing it correctly.


My point here is we are human and we are fallible.  The sooner we 
acknowledge and internalise that, the better equipped we are to 
make systems that don't suck for humans to use.


In that sense, I don't even really like this format because it's 
still not especially resilient.  Walter's talk about design that 
eliminates patterns of human error resonated with me quite 
strongly, you see.  But in terms of language consistency it's not 
much different from array literals, so I could accept it as a 
compromise.


-Wyatt

Re: Why I chose D over Ada and Eiffel

2013-08-20 Thread Andrej Mitrovic

On 8/19/13, Ramon s...@thanks.no wrote:
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).

UTF-8 can deal with every language as well. But perhaps you meant
something else here.

Anyway welcome aboard!

Re: A Discussion of Tuple Syntax


On 08/20/2013 12:38 PM, eles wrote:


What about:

!!(a, b)



This already has a meaning.

Re: std.serialization: pre-voting review / discussion

Ok, I was trying to avoid expressing personal opinion until now
and mostly keep track of comments of others but now that I have
started reading docs/sources in details, will step down from
review manager role for a moment and do some very subjective
reviewing :)

---

Hot topic first. Ranges. As far as I can see it it is not about
lets stick range API whenever possible because it is the way
Phobos does things. Key moment here to recognized use cases that
are likely to require range-based interface and focus on them.

As far as I can see it there two important places where
possibility for range-based API can be helpful - providing values
for serialize and providing raw data to deserialize, as well as
matching Archiver changes.

Former is relatively trivial - serialize should have an
overload that accepts InputRange of monotyped values to take care
of and provides ForwardRange as a result, which serializes values
one-by-one lazily. Same goes to archiver.

Latter is a bit more interesting. It would have been cool if
instead of accepting raw data chunk that matches deserialized
object size serializer.deserialize could have accepted InputRange
that provides sequence of any random chunks of raw data and use
it to construct values on per-request basis, lazily. This will
require maintaining a buffer that will keep unconsumed remainder
of the last chunk and make some decisions about behavior in case
of hitting empty() before getting enough data to deserialize
object.

But it is not be something you should care about right now
because only actual function/method signatures are needed with
static asserts insides, actual implementation can be added later
by anyone willing to spend time.

---

Now about my personal feeling about std.serialization as a
potential user. Core functionality I'd like to see in such module
is the ability to dump D data type state into arbitrary formats
in a robust way that requires minimal interference from the user
code. Something like what is done with toJSON/fromJSON in vibe.d
API stuff but more generic when in comes to output formats and
more robust when it comes to data hierarchies to load/store.

Judging by examples and documentation this is exactly what
std.serialization does and I like it. It lacks some better output
(Archiver) choices but it is more like Phobos fault.

What I really don't like is excessive amount of object in the
API. For example, I have found no reason why I need to create
serializer object to simply dump a struct state. It is both
boilerplate and runtime overhead I can't justify. Only state
serializer has is archiver - and it is simply collection of
methods on its own. I prefer to be able to do something like
`auto data = serialize!XmlArchiver(value);`

That is not something that would have made me vote against the
inclusion (I think it is much needed anyway) but that may have
discouraged me from using this part of Phobos and fall to some
NIH syndrome.

I have found documentation complete enough to get a basic
understanding personally but one thing that has caused some
frustration is that docs don't make clear distinction between
minimal stuff and extra features. For example, there is
https://dl.dropboxusercontent.com/u/18386187/docs/std.serialization/std_serialization_serializable.html
- my guess that it is only used if user wants to override default
serialization method for an aggregate type. But documentation for
it is written in such manner that it gives an impression that it
is absolutely required.

---

Last thing is not really relevant but is more about general
documentation problem. This may be the first package that makes
use of new package.d system and it shows that we need some way
to provide package-wide documentation to keep things clear. I
guess for DDOC itself generating output from package.d is nothing
special - but what about dlang.org? How hard will it be to update
a documentation page to support own block for package roots?

Re: Ideas for a brand new widget toolkit

2013-08-20 Thread Adam D. Ruppe


On Friday, 16 August 2013 at 22:22:06 UTC, Jonas Drewsen wrote:

Awesome... looking forward to have a look at it.


I pushed the changes to my github today. Still a few little 
changes I want to make, but nothing major. (for example, the 
input enum is based on my US keyboard, so it doesn't have entries 
for other keys. But that's generally additive so should be be 
major breakage.)


https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff

simpledisplay.d and color.d are the two you'll need.


To make an OpenGL window:


import simpledisplay;
auto win = new SimpleWindow(Size(400, 400), GL Test, 
OpenGlOptions.yes);


 // this uses a delegate so it can be automatically called 
when the window is uncovered

win.redrawOpenGlScene = {
   glBegin(GL_QUADS);
   // blah blah blah
   glEnd();
}

win.redrawOpenGlSceneNow();
win.eventLoop(0);


I'm not completely happy with this and might change some things, 
but the meat is there now. simpledisplay.d includes some opengl 
function definitions, but not all of them.


On Windows, you need to explicitly add -version=with_opengl and 
get your own opengl32.lib and glu32.lib since they don't come 
with dmd yet. (I wish Walter would reply to that thread!)

Re: A Discussion of Tuple Syntax

2013-08-20 Thread Meta

This is the reason I had originally thought Kenji's DIP was about 
run-time tuples. If it's just syntactic sugar over 
std.typecons.Tuple (plus some extra destructuring/pattern 
matching stuff), it would require no ABI changes and no changes 
to TypeTuple semantics. The one thing it wouldn't do is unify 
Tuple and TypeTuple.


However, with compiler support, we can make this situation 
better. TypeTuple stays as-is, while Tuple becomes a value 
instead of a type, which has its own literal syntax. This means 
that typeof(tuple(1, a)) is not Tuple!(int, string), as in the 
struct, but TypeTuple!(int, string), as in the compiler tuple.


You could still do all the stuff that can be done with TypeTuple 
currently, but it should be strongly discouraged to mix types and 
values within TypeTuple, or even limited by the compiler. This 
creates a clear distinction between runtime tuples and TypeTuple. 
It becomes much easier to reason about their semantics, as we can 
think of TypeTuple as a type, just like int, string, double, 
etc., and Tuple as a value, just like 1, a, 2.3, etc. The only 
difference between TypeTuple and regular types is that there are 
a few special static operations that can be used to manipulate 
it. Otherwise it behaves as a type.

Re: std.serialization: pre-voting review / discussion


On 2013-08-20 10:01, Walter Bright wrote:


Thank you, Jacob. It looks like you've put a lot of nice work into this.

I've perused the documentation, and all I can think of is What's a cubit?

http://www.youtube.com/watch?v=so9o3_daDZw

I.e. there are 9 documentation pages of details. There's no obvious
place to start, no overview, no explanation of what serialization is for
and why I might want to use it and what's great about this
implementation. At least none that I could find. Also needs some
non-trivial canonical example code.

Something that answers who what where when why and how would be
immensely useful.


Yes, I need to add some overview documentation. There's still the 
problem of finding the overview.



Some nits:

https://dl.dropboxusercontent.com/u/18386187/docs/std.serialization/std_serialization_serializationexception.html


Something went horribly wrong here:

Parameters:
Exception exception the exception exception to wrap



Hehe, yeah :)


https://dl.dropboxusercontent.com/u/18386187/docs/std.serialization/std_serialization_registerwrapper.html


Lacks an illuminating example.


That doesn't need to be ddoc comments at all. The whole module is 
declared package. I would be really nice if ddoc could automatically 
hide anything that wasn't public or protected but still generate the 
documentation for package and private.



https://dl.dropboxusercontent.com/u/18386187/docs/std.serialization/std_serialization_serializer.html


When would I use a struct Array or a struct Slice?


Same as above. I'll see if they really have to be public.


https://dl.dropboxusercontent.com/u/18386187/docs/std.serialization/std_serialization_attribute.html


struct attribute should be capitalized. When would I use an attribute?
Does this have anything to do with User Defined Attributes? Need a
canonical example.


Same as above.

I have used lower case because I don't consider this a struct, yes 
technically it is. This is an attribute (UDA) and I think attributes 
should be lower case. Or rather it's supposed to be used on types to 
indicate they are UDA's:


@attribute struct foo {}

The reason for this is that I'm a bit disappointed in the implementation 
of UDA's in D. I would have liked to have some kind of entity that I can 
point to and say this is an attribute. Currently all random values and 
types can be used as an UDA, I don't like that.


Same idea why to have interface and abstract keywords. It's possible 
to avoid these, i.e. C++, but I think it's a lot better to have them.



https://dl.dropboxusercontent.com/u/18386187/docs/std.serialization/std_serialization_archives_archive.html


Aren't interfaces already abstract? I.e. abstract is redundant.


I have no idea why abstract is added there. The definition looks like 
this:


https://github.com/jacob-carlborg/phobos/blob/serialization/std/serialization/archives/archive.d#L88


The documentation defines an archive more or less as an archive. I still
don't know what an archive is.


The archive is the backend in the serialization process.

And

The archive is responsible for archiving primitive types in the format 
chosen by the archive implementation. The archive ensures that all types 
are properly archived in a format that can be later unarchived.



(E.g. a zip file is an archive - can this create zip files?)


Theoretically one can create an archive that serializes to a zip file, 
yes. Or rather the format used by zip. An archive shouldn't write to disk.


--
/Jacob Carlborg

Re: When compiling multiple source files


On Tuesday, 20 August 2013 at 13:30:11 UTC, Jacob Carlborg wrote:

On 2013-08-20 13:21, John Colvin wrote:


Only 2GB

It can work... but I have to close everything else running 
first,
otherwise it locks everything up and then crashes out 
complaining about

not having enough memory to fork.


Hmm, I'm pretty sure I have compiled Phobos on my MacBook, 
which only has 2GB.


Just from looking at htop while compiling, it looks like it uses 
approx. 800MB to compile phobos. It's not unusual for me to have 
a lot less than that free at any given time.


The interesting thing is that it crashes instead of just 
swapping...

Re: When compiling multiple source files


On 2013-08-20 13:21, John Colvin wrote:


Only 2GB

It can work... but I have to close everything else running first,
otherwise it locks everything up and then crashes out complaining about
not having enough memory to fork.


Hmm, I'm pretty sure I have compiled Phobos on my MacBook, which only 
has 2GB.


--
/Jacob Carlborg

Re: When compiling multiple source files


On 08/20/2013 12:27 AM, 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
...


The compiler only has to pull in what is indispensable for semantically 
analyzing an imported module as far as to determine all relevant type 
signatures. So while it should be possible to create a project as large 
that the complete annotated syntax tree exhausts your RAM (projects are 
not that large in practice), it still would require careful construction 
of dependencies in order to actually exhaust RAM during separate 
compilation. (And it is much easier to do so by other means, eg. by 
instantiating templates in a loop.)

Re: Ideas for a brand new widget toolkit

2013-08-20 Thread Adam D. Ruppe


On Monday, 19 August 2013 at 21:01:49 UTC, Ramon wrote:
- looking for some kind of GUI-kit that is less massive than 
gtk, qt, etc. and runs pretty everywhere.


I'm now working on a minigui.d and pushed a very incomplete start 
to my github:


https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/minigui.d

Also depends on simpledisplay.d and color.d from the same repo. 
There's still a *lot* I have to finish and change in there, but 
you can see my basic direction:


1) somewhat thinly wrap Win32 controls, then DIY to similar 
functionality on X for cross platformness. If you add a manifest 
resource/file, this uses the theming api too, so on WinXP it 
looks like an XP app, on Vista it looks like vista, etc.


2) Minimal dependencies, I'm not even using Phobos in here. The 
result: my test program is a 205 KB exe on Windows, with no dlls 
needed at runtime (except those that come with Windows), and you 
can compile it with just my three files, no need for special 
instructions to build the library, just add them to your dmd 
command line. (I'm even considering merging it into two files.)


3) The event model is kinda like javascript and the widget layout 
is a simple stretchy thing based on max/min width/height and a 
stretchiness factor.


4) Drawing is possible through simpledisplay.d's ScreenPainter or 
Open GL functions.



I'm about halfway to where I want to be with this now. After 
making the Windows impl good and the X impl barely working, I'll 
go back and see about making the X one slightly prettier and 
better functioning, but my emphasis is still on small size so 
don't expect too much. (One option would be to do GTK similarly 
like Windows as an option for nicer X version.)


Then if I still have time, I'll look at my would be nice list: a 
text mode alternative backend, a html5 thingy, and my plans for 
network transparency and detaching as discussed earlier in the 
thread.


But for now, I'm aiming low.

Re: OT; Will MS kill .NET ?

2013-08-20 Thread Paulo Pinto


On Tuesday, 20 August 2013 at 12:49:36 UTC, Luís Marques wrote:

On Tuesday, 20 August 2013 at 07:45:28 UTC, Paulo Pinto wrote:
...
I don't quite agree with this. Imagine if I said they just 
have to change their Javascript compilers to produce native 
code. It's clear that the semantics of the JS language do not 
map well enough to the x86 semantics for us to consider the 
produced x86 code to be fully native. It would be x86 code, 
but you wouldn't be able to do systems programming, like in C++ 
or D. To a lesser extent the same is true with, say, C#. The 
design of the language makes it less native to a x86 CPU than 
C++.


Native code has nothing to do with systems programming or the 
mapping of

one-to-one from language to microprocessor instructions.

Before the Java and .NET craziness, VM everywhere, all mainstream
compilers generated native code.

Had Sun and Microsoft decided to generate native code instead of 
their current solution, we wouldn't even be discussing this.


This managed vs native is a marketing concept spread by Microsoft 
when they introduced .NET and wanted to make a distinction when 
talking to Windows developers.


And the main reason why young developers now think that any 
strong typed language needs to be executed by a VM.


Language semantics always matter, regardless how the code is 
generated.


--
Paulo

Re: When compiling multiple source files


On 08/20/2013 08:50 AM, Jacob Carlborg wrote:

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.



I was under the impression that this is a limitation of DMD and will be 
fixed, right?

Re: std.serialization: pre-voting review / discussion

2013-08-20 Thread Daniel Murphy

Dicebot pub...@dicebot.lv wrote in message 
news:luhuyerzmkebcltxh...@forum.dlang.org...

 What I really don't like is excessive amount of object in the API. For 
 example, I have found no reason why I need to create serializer object to 
 simply dump a struct state. It is both boilerplate and runtime overhead I 
 can't justify. Only state serializer has is archiver - and it is simply 
 collection of methods on its own. I prefer to be able to do something like 
 `auto data = serialize!XmlArchiver(value);`


I think this is very important.  Simple uses should be as simple as 
possible.

Re: Possible solution to template bloat problem?


On Tuesday, 20 August 2013 at 01:33:08 UTC, H. S. Teoh wrote:

[...]

Reminds me: how hard is writing own linker is again? :)


Honestly, I think it's about time linker technology is 
rethought and

developed further.


Actually, I was asking about this not because there are critical 
issues with existing linker technology. While it definitely has a 
lot of space for improvements, even good old `ld` has plenty of 
features that do matter. Collection of unused sections that was 
already mentioned can result in huge binary size improvements. 
I'd love to enable this by default - problem is we can't rely on 
platform-specific tools to define such an important feature 
tightly coupled with language itself (think about `export`).

Re: Why I chose D over Ada and Eiffel

2013-08-20 Thread monarch_dodra


On Tuesday, 20 August 2013 at 12:59:13 UTC, Andrej Mitrovic wrote:

On 8/19/13, Ramon s...@thanks.no wrote:
   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).


UTF-8 can deal with every language as well. But perhaps you 
meant

something else here.

Anyway welcome aboard!


I think he meant that every modern spoken/written language fits 
in the Basic Multilingual Plane, for which each codepoint fits 
in a single UTF16 code unit (2 bytes). Multiple codeunit 
uncodings in UTF-16 are *very* rare.


On the other hand, if you encode japanese into UTF-8, then you'll 
spend *3* bytes per codepoint, ergo, wasted memory.


@ Ramon:
I think that is a fallacy:
http://en.wikipedia.org/wiki/UTF-8#Compared_to_UTF-16
Real world usage is *dominated* by ASCII chars. Unless you have a 
very specific use case, then, UTF8 will occupy *less* room than 
UTF16, even if it contains a lot of foreign characters.


Furthermore, UTF-8 is pretty much the standard. If you keep 
UTF-16, you will probably end up regularly transcoding to UTF-8 
to interface with char* functions.


Arguably, the only (IMO) usecase for UTF-16, is interfacing 
with windows' UCS-2 API. But even then, there'll still be some 
overhead, to make sure you don't have any dual-encoded in your 
streams.

Re: A Discussion of Tuple Syntax


On Tuesday, 20 August 2013 at 13:17:44 UTC, Meta wrote:
This is the reason I had originally thought Kenji's DIP was 
about run-time tuples. If it's just syntactic sugar over 
std.typecons.Tuple (plus some extra destructuring/pattern 
matching stuff), it would require no ABI changes and no changes 
to TypeTuple semantics. The one thing it wouldn't do is unify 
Tuple and TypeTuple.


Syntax sugar will only hide and eventually increase confusion, it 
won't solve the semantical issue. This is why we are having this 
topic IMHO, bunch of quite experienced D developers can't even 
agree on how existing feature behaves :) Including those who is 
it all the time! It is clear indicator that syntax is not the one 
to blame.


However, with compiler support, we can make this situation 
better. TypeTuple stays as-is, while Tuple becomes a value 
instead of a type, which has its own literal syntax. This means 
that typeof(tuple(1, a)) is not Tuple!(int, string), as in 
the struct, but TypeTuple!(int, string), as in the compiler 
tuple.


I am proposing something more radical. Deprecate _both_ TypeTuple 
and Tuple. Clearly define the difference between built-in type 
tuple and expression tuple (latter being instance of former). 
Preserve auto-expansion. Provide two different literals to remove 
ambiguity between referencing symbol as a value and referencing 
it as an alias. Make compiler auto-generate Tuple-like struct 
type for expression tuples that need to be returned from 
functions. Create some new type in std.typecons for those who 
don't want auto-expansion.


It won't even break stuff.

Re: Why I chose D over Ada and Eiffel

2013-08-20 Thread Joseph Rushton Wakeling


On 20/08/13 00:00, Walter Bright wrote:

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.


On that note -- I was chatting with a (very functional- and Lisp-oriented) 
friend about D and, when ranges were mentioned, he immediately connected it with 
Clojure's concept of sequences: http://clojure.org/sequences


Does anyone know the history/relationship here between these and D's ranges? 
Was it a direct influence from D, or convergent evolution -- and can anyone 
comment on the relative merits of the D vs. Clojure approaches?

Re: A Discussion of Tuple Syntax

2013-08-20 Thread Meta


On Tuesday, 20 August 2013 at 13:57:49 UTC, Dicebot wrote:
Syntax sugar will only hide and eventually increase confusion, 
it won't solve the semantical issue. This is why we are having 
this topic IMHO, bunch of quite experienced D developers can't 
even agree on how existing feature behaves :) Including those 
who is it all the time! It is clear indicator that syntax is 
not the one to blame.


My suggestions are predicated on the fact that I think tuples are 
more or less fine as-is. They just need some syntactic sugar for 
literals and destructuring/pattern matching to make them more 
usable. Built-in tuples are confusing, I think, because they're 
named TypeTuple, which makes people conflate them with 
std.typecons.Tuple.


Another reason is that TypeTuple can contain both values and 
types at the same time, so it's confusing as to what you can do 
with them.


Why can you only assign a TypeTuple to a variable if it contains 
values but not types? Why, then, can't you return TypeTuple!(1, 
2.3) from a function? Is it not really a variable? Why does 
`alias t = TypeTuple!(1, 2.3)` work, but `alias n = 3` not work? 
Is this f*$#ing thing a value or a type? - D Newbie


Everything else aside, I think the best possible change that 
would make the whole tuple situation better is to limit or 
outright ban the mixing of values and types within TypeTuple. 
Even better is to always treat TypeTuple as a type, and not a 
value. That ship has already sailed, but we can at least try to 
enforce it through convention.


I am proposing something more radical. Deprecate _both_ 
TypeTuple and Tuple. Clearly define the difference between 
built-in type tuple and expression tuple (latter being instance 
of former). Preserve auto-expansion. Provide two different 
literals to remove ambiguity between referencing symbol as a 
value and referencing it as an alias. Make compiler 
auto-generate Tuple-like struct type for expression tuples that 
need to be returned from functions. Create some new type in 
std.typecons for those who don't want auto-expansion.


It won't even break stuff.


I think my position has changed to suggest nearly the same thing. 
There needs to be a clear separation between built-in tuples and 
tuple values. A runtime tuple literal syntax helps with that. 
Making typeof(tuple(1, 2.3)) == TypeTuple!(int, double) helps as 
well, because it is now clear that one is a value and one is a 
type. Limiting the mixing of values and types within TypeTuple 
helps with that.


This would allow both Tuple and TypeTuple to be deprecated. Tuple 
wouldn't be needed anymore, because we would have a literal 
syntax to replace it. It would only be there for backwards 
compatibility. With Tuple deprecated, std.typetuple.TypeTuple 
could be renamed Tuple, and we would then have only one thing 
with the name Tuple in the language.

Re: A Discussion of Tuple Syntax

On Mon, Aug 19, 2013 at 09:41:24PM -0700, Jonathan M Davis wrote:
 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.
[...]

That's a classic. I'm st^H^H borrowing that for my random signatures
file. :)


T

-- 
There's light at the end of the tunnel. It's the oncoming train.

Re: Why I chose D over Ada and Eiffel

On Tue, Aug 20, 2013 at 08:58:54AM +0200, Jacob Carlborg wrote:
 On 2013-08-19 23:17, H. S. Teoh wrote:
 
 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*).
 
 Oh, what I wish that was true. We're still struggling with encoding
 problems at work due to browsers and third party services and tools
 not being able to handle Unicode.
[...]

Well, I was referring to languages and systems invented today. Obviously
there is still a large amount of legacy code that can't handle Unicode
yet, but any new language or new system invented today has no excuse to
not support Unicode.


T

-- 
Those who've learned LaTeX swear by it. Those who are learning LaTeX
swear at it. -- Pete Bleackley

Re: Why I chose D over Ada and Eiffel

On Tue, Aug 20, 2013 at 11:19:27AM +0200, Chris wrote:
 On Tuesday, 20 August 2013 at 07:08:08 UTC, Jacob Carlborg wrote:
 
 You can use this tool to automatically generate bindings to C
 libraries:
 
 https://github.com/jacob-carlborg/dstep
 
 
 Great stuff, Jacob! Congratulations.
 
 One thing that is usually not mentioned in articles about D is that
 you don't need an IDE to develop in D. This was, if I remember it
 correctly, one of the design goals.

Was it a design goal? If so, kudos to Walter. :) Because one of my
criteria for a better programming language when I decided that I was fed
up with C++ and needed something better, was that it must not have undue
reliance on an IDE or some other external tool to be usable. Thus, Java
was disqualified (too much boilerplate that can't be adequately handled
without an IDE -- of course, there were other factors, but this was a
big one). It must be usable with just a text editor and a compiler. D
fit that criterion rather nicely. :)


T

-- 
If creativity is stifled by rigid discipline, then it is not true creativity.

Re: Why I chose D over Ada and Eiffel

2013-08-20 Thread Wyatt


On Monday, 19 August 2013 at 21:19:05 UTC, H. S. Teoh wrote:


scope guards. If I were granted a wish for how to lessen the 
pain of

coding in C, one of the first things I'd ask for is scope.


A little OT at this point, but C Survival Kit might have you 
sufficiently covered:

https://github.com/chadjoan/C-Survival-Kit/blob/master/survival_kit/feature_emulation/scope.h
(Been considering pulling this in at work, too.)

-Wyatt

Re: A Discussion of Tuple Syntax

2013-08-20 Thread Manu

On 20 August 2013 16:39, Timon Gehr timon.g...@gmx.ch wrote:

 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)?


 - ABI

 Multiple return values could use a more efficient ABI than struct
 instances because they do not have an address.


*** this

I've been banging this drum for years!

However this discussion resolves, I just hope it allows for convenient and
efficient MRV's.
Obviously it should be syntactically convenient, and assignment of MRV to
callee locals should be convenient too.
But more importantly, I'd like to see ALL the argument registers re-used to
return multiple values, rather than just the first one. They're just
sitting there begging to be used, and in many cases, would lead to some
great efficiency improvements across function calls/returns. Especially on
non-x86 architectures.

Perhaps one of the most common causes for (otherwise unnecessary) inlining
of functions is because of the terrible legacy ABI for returning multiple
values from functions.

Re: Ideas for a brand new widget toolkit


Front up:

As it seems nobody heftily disagrees with my groupings. While I
myself am (as probably many others) in the 1  3 camp (looking
for some kind of GUI-kit that is less massive than gtk, qt, etc.
and runs pretty everywhere. - and - Add a GUI toolkit to D) I
took note that there is also a not insignicant need from the 2
group (Looking for sophisticated GUI, possibly mainly for games,
video
etc.).

If I'm not badly mistaken, the 2 groups needs will basically
need/could be addressed by OpenGL. *Please, correct me, if I'm
fundamentally wrong!*


On Tuesday, 20 August 2013 at 01:28:10 UTC, Gambler wrote:
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).


Well, yes and no. Actually I think that pretty everyone here
(i.e. people who have a gui need of whatever detail sort) does
have a pretty clear picture of reasonable basics. Let me name
it:

- Windows (surprise! *g)
- Menus
- the standard controls (text boxes, lists, combos, ...)
- font handling
- supporting well established mechanisms like DragnDrop
- and - importantly - a design that allows for creation of more
complex widgets (like spreedsheats) using the basic ones.

On Tuesday, 20 August 2013 at 07:15:38 UTC, Jacob Carlborg wrote:

On 2013-08-19 23:01, Ramon wrote:

- 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.


If native controls are used then the first step is make sure we 
have proper and easy to use bindings to these. For example, 
it's a PITA to access Objective-C frameworks (needed for Mac OS 
X) form D. So we need this:


Thanks a lot! Important point.
While there has not yet been defined a list of targets I
assume,pretty everybody can agree on Win/X11/Mac and possibly
Android (?) with the letter as well as other more exotic targets
being more of a we had it in mind and ried har to not block the
road, did however not build it for the time being kind, right?

Which brings up another important point:

Of course, it's seductive to just get something working. At the
same time though I suspect this attitude to be a major factor for
GUI kits not having been finished or having been condemned to
insignificance.

I'd strongly suggest to not too quickly go to the let's hack it
phase but rather to properly develop a design that is sound,
allows for future changes and improvements (wayland, iphone, ...).

That's true for languages, DBs and other stuff, too. The good and
widely accepted ones have a clear philosophy and design behind
them, the insigificant or bad ones don't.
Sure, a programmers, we prefer coding but frankly, as *mature*
developers we know about the importance of thinking, discussing
and pondering before approaching the keyboard, don't we?


@Adam D. Ruppe

Thank you. I think those etudes can be very helpful. I suggest,
however, no matter how attractive it might be, to *not* just grab
something and hack on it but (sorry for repeating myself) to
think well and profoundly about important criteria and a
philosophy and only then begin to develop a sound design
(before we start to hack the beast).

One seemingly paradoxical reasoning behind my point of view is
that we (well, most of us anyway) are not in the gui and graphics
business but merely developers who need a major itching
scratched, preferably once and for all.

Thinking properly about it we will, if, say, a major new OS
target or windowing system comes up, be able to quite quickly
port our gui and be done with it.

Another issue that we might underestimate are colleagues using
completely different languages, say, Python. Shouldn't they - and
wouldn't they love to - have a chance to grok/bind our D gui into
their language, too? And wouldn't that be a major and quite
convincing advertisement for D?

Thanks everyone for your patience with my long posts - Ramon

Re: A Discussion of Tuple Syntax


Kenji Hara:

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.


With your idea is there a way to unpack a short array into 
variables? This is an handy operation I do often in Python:




s = red blue
(a, b) = s.split()
a

'red'

b

'blue'


Bye,
bearophile

Re: [dox] C++ Interfaces

2013-08-20 Thread Wyatt


On Tuesday, 20 August 2013 at 08:00:56 UTC, Atash wrote:

This link: http://dlang.org/CPP-Interfaces

Is made on this page: http://dlang.org/interface.html

And I *think* (not sure) that since whatever it was originally 
pointing to has disappeared, it should probably end up pointing 
here:


http://dlang.org/cpp_interface.html


That looks right.

Maybe add an anchor to about halfway down the page, so it'd 
look more like:


http://dlang.org/cpp_interface.html#extern-CPP-interfaces

Not quite sure why you'd do this.  The cpp_interface.html gets to 
the example meat fairly quickly.  Unless you're talking about 
turning the Calling Global D Functions From C++ heading into an 
anchor?


In general, you'll find the docs could stand to have a lot more 
anchors in general.



vast wilds of newbie-dom... What do?


For the time being, I'd make a pull request that changes the link 
on the interface page to the correct URI.  That's the bare 
minimum.


-Wyatt

Re: std.serialization: pre-voting review / discussion

2013-08-20 Thread Tyler Jameson Little


On Tuesday, 20 August 2013 at 13:44:01 UTC, Daniel Murphy wrote:

Dicebot pub...@dicebot.lv wrote in message
news:luhuyerzmkebcltxh...@forum.dlang.org...


What I really don't like is excessive amount of object in the 
API. For example, I have found no reason why I need to create 
serializer object to simply dump a struct state. It is both 
boilerplate and runtime overhead I can't justify. Only state 
serializer has is archiver - and it is simply collection of 
methods on its own. I prefer to be able to do something like 
`auto data = serialize!XmlArchiver(value);`




I think this is very important.  Simple uses should be as 
simple as

possible.


+1

This would enhance the 1-liner: write(file, 
serialize!XmlArchiver(InputRange));


We could even make nearly everything private except an 
isArchiver() template and serialize!().

Re: A Discussion of Tuple Syntax


s = red blue
(a, b) = s.split()
a

'red'

b

'blue'


It's supported in Haskell too:

Prelude let s = red blue
Prelude let [a, b] = words s
Prelude a
red
Prelude b
blue

Bye,
bearophile

Re: Possible solution to template bloat problem?


On 08/20/2013 02:34 AM, 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.


If real generics means polymorphic type system then the difference is 
that templates are not part of the type system.

Re: Why I chose D over Ada and Eiffel

2013-08-20 Thread Chris


On Tuesday, 20 August 2013 at 14:35:19 UTC, H. S. Teoh wrote:

On Tue, Aug 20, 2013 at 11:19:27AM +0200, Chris wrote:
On Tuesday, 20 August 2013 at 07:08:08 UTC, Jacob Carlborg 
wrote:


You can use this tool to automatically generate bindings to C
libraries:

https://github.com/jacob-carlborg/dstep


Great stuff, Jacob! Congratulations.

One thing that is usually not mentioned in articles about D is 
that
you don't need an IDE to develop in D. This was, if I remember 
it

correctly, one of the design goals.


Was it a design goal? If so, kudos to Walter. :) Because one of 
my
criteria for a better programming language when I decided that 
I was fed
up with C++ and needed something better, was that it must not 
have undue
reliance on an IDE or some other external tool to be usable. 
Thus, Java
was disqualified (too much boilerplate that can't be adequately 
handled
without an IDE -- of course, there were other factors, but this 
was a
big one). It must be usable with just a text editor and a 
compiler. D

fit that criterion rather nicely. :)


T


I don't know if it's still on the website here somewhere. But I 
remember reading (2 years or so ago) that D shouldn't require a 
big IDE but should be manageable using a text editor and a 
compiler. And it is true. So far, I haven't used an IDE for my D 
programming.

Re: A Discussion of Tuple Syntax

bearophile I really respect informational contribution you have 
been doing in D community but in my opinion mentioning random 
snippets from other languages is the least useful thing possible 
in this thread. It is even less useful than discussing syntax.

Re: A Discussion of Tuple Syntax

2013-08-20 Thread Kenji Hara

2013/8/20 Dicebot pub...@dicebot.lv

 What we have here are two completely different _built-in_ tuple types. T
 is pure template arguments list and is pretty much equal TypeTuple!(int,
 int). But what is args? It uses the very same built-in tuple syntax but
 it is much closer to std.typecons.Tuple in its behavior (actually, latter
 is implemented in terms of it as I was pointed out) - it is an entity that
 provides abstraction of top of group of run-time values. It does not have
 any binary structure on its own (built on top of existing values) but
 observable semantic are very run-time'ish.


args is a built-in tuple of two function parameter variables. In binary
level, args[0] and args[1] could be bounded to completely individual
storage. (Even if args[1] is on stack, args[0] may be on register)
On the other hand, std.typecons.Tuple is a struct. Its second field has the
memory address which follows of the first field.

What bothers me is the question can we clean this up and bring those two
 worlds together, even at cost of minor breakage?. I am not speaking about
 literals here or unpacking or whatever. I am speaking about re-defining
 semantics so that struct-based Tuple and built-in syntax sugar in form of
 run-time expression tuple both get merged into one built-in construct which
 can be used in wider variety of places.


 At least right now I can't find any technical objections why expression
 tuple can't use std.typecons.Tuple ABI when returned from function but
 still be automatically expanded when passed into functions. Kenji, what is
 your your opinion about complexity to implement something like that in DMD?


Automatically packing/unpacking would need hidden runtime cost.

Kenji Hara

Re: A Discussion of Tuple Syntax


On Tuesday, 20 August 2013 at 15:43:39 UTC, Kenji Hara wrote:
On the other hand, std.typecons.Tuple is a struct. Its second 
field has the

memory address which follows of the first field.


Yes but as you have said exact storage of built-in tuple elements 
is not defined - it can be distinct elements or struct fields, 
compiler is free to chose any. I am not asking about internal 
implementation but about behavior observable by user in typical 
cases - it is most important topic here.



Automatically packing/unpacking would need hidden runtime cost.


Will it be any more costly then returning std.typecons.Tuple and 
unpacking it manually? And, well, do we have _any_ other option 
of returning a tuple with no runtime costs right now anyway?


Considering we are far away from stable ABI that does not seem to 
be a real issue.

Re: A Discussion of Tuple Syntax

2013-08-20 Thread eles


On Tuesday, 20 August 2013 at 13:14:46 UTC, Timon Gehr wrote:

On 08/20/2013 12:38 PM, eles wrote:


What about:

!!(a, b)



This already has a meaning.


True :( I dunno why I took it for some kind of binary operator 
instead of a unary one.


I was too quick on my keyboard.

Re: A Discussion of Tuple Syntax

2013-08-20 Thread Kenji Hara

2013/8/20 bearophile bearophileh...@lycos.com

 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.


 With your idea is there a way to unpack a short array into variables? This
 is an handy operation I do often in Python:

  s = red blue
 (a, b) = s.split()
 a

 'red'

 b

 'blue'


My position to such a feature is constant. We should not conflate tuple
unpacking and array unpacking.

But, extending unpacking syntax mentioned in DIP32 might help it.

// Just an idea: extending DIP32 unpacking syntax
import std.typecons : tuple;
auto tup = tuple(1, tuple(2,3), [4,5]);
{ auto a, {b, c}, [d, e] } = tup;
//{ auto a, [b, c], {d, e} } = tup;   // cause compile-time error
assert(a == 1);
assert(b == 2  c == 3);
assert(d == 4  e == 5);

However, array unpacking would require *hidden* runtime boundary check.
In above example code,

  assert(tup[2].length == 2);
  // or
  if (tup[2].length != 2) throw Error(Runtime mismatch of unpacking
pattern);
  // or similar

should be implicitly inserted by compiler, even in @system code.
I'm not sure that is acceptable cost or not.

Kenji Hara

Re: OT; Will MS kill .NET ?

2013-08-20 Thread Kagamin


http://msdn.microsoft.com/en-us/library/system.type.makegenerictype.aspx
How would you implement this in native code?

Re: A Discussion of Tuple Syntax


Dicebot:

bearophile I really respect informational contribution you have 
been doing in D community but in my opinion mentioning random 
snippets from other languages is the least useful thing 
possible in this thread. It is even less useful than discussing 
syntax.


Look better at them, those aren't random snippets, they show one 
more case of de-structuring, creating a tuple of variables out of 
an array. It's a commonly used operation in two very well 
designed languages that have tuples. Here we are discussing 
tuples and their packing and unpacking, so the two examples I've 
shown are very relevant, even if we decide to not support that 
specific feature.


Bye,
bearophile

Re: A Discussion of Tuple Syntax


Kenji Hara:


My position to such a feature is constant.


Even if your opinion is not changed, I have to show that common 
tuple-related features to the other persons that are reading this 
thread, because it's an an idea to keep in account (even if it's 
refused), and some other person could have an opinion different 
from yours.



However, array unpacking would require *hidden* runtime 
boundary check.

In above example code,

  assert(tup[2].length == 2);
  // or
  if (tup[2].length != 2) throw Error(Runtime mismatch of 
unpacking

pattern);
  // or similar

should be implicitly inserted by compiler, even in @system code.
I'm not sure that is acceptable cost or not.


Runtime boundary checks and tests are not needed if you unpack a 
fixed-sized array:


auto tup = Tuple!(int, string[2])(1, [red, blue]);
auto {x, [c1, c2]} = tup;

Regarding the de-structuring of dynamic arrays, I think it's not 
too much different than this:


void main() {
int[] a = [10, 20, 30];
int[2] b = a;
}

If you compile and run it without switches, you get at run-time:

object.Error: lengths don't match for array copy, 2 = 3


While I receive no run-time errors if I compile with 
-noboundscheck.


Bye,
bearophile

Re: OT; Will MS kill .NET ?

2013-08-20 Thread Luís.Marques


On Tuesday, 20 August 2013 at 13:37:00 UTC, Paulo Pinto wrote:
Native code has nothing to do with systems programming or the 
mapping of one-to-one from language to microprocessor 
instructions.


At least in the context of fully native and C#, which we were 
discussing, I disagree. See below.


Before the Java and .NET craziness, VM everywhere, all 
mainstream compilers generated native code.


Had Sun and Microsoft decided to generate native code instead 
of their current solution, we wouldn't even be discussing this.


If I understand your point, you are defining (fully?) native as 
simply generating CPU opcodes and executing those directly. But I 
think this definition can be unhelpful, because there is an 
equivalence and a continuum between code and data. For instance:


  1. Compiler generates x86 code, which is executed directly by 
the CPU, and nearly all the source program operations (setting a 
variable, calling a function, etc.) are encoded directly in the 
produced code. E.g. setting a variable is done directly with a 
mov opcode.


  2. Compiler generates x86 code, which is executed directly by 
the CPU, but some program operations are done indirectly using 
helper functions/code which was not described in the source code. 
E.g. setting a variable with memcpy (silly example), creating a 
closure (actual D example, which uses a D runtime function).


  3. The compiler generates x86, which is executed directly by 
the CPU, but a lot of the source program logic is encoded as data 
or calls to helper functions. This tends to happen when you try 
to produce native code for scripting languages: instead of 
dispatching bytecode operations using a switch(...) as you would 
do in a typical interpreter, you call/execute helper code 
directly (so we are still native in a certain sense). But the 
program logic (e.g., a+b) mostly happens in those helper 
functions/code the compiler generates, because the semantics of 
the language (e.g. prevent overflows when multiplying big numbers 
by converting to arbitrary precision) demand those operations, 
which don't have direct counterparts in the CPU ISA.


  4. You refactor those helper functions in a VM, and generate 
bytecode which when interpreted will call them, instead of 
calling them directly.


Etc. My point was that when the source language semantics allows 
you to express constructs which can be directly and efficiently 
executed by the CPU ISA (systems programming would be an 
extreme of that) then you can probably say that you are being 
fully native (bar assembly language programming). When your 
Turing complete language can never be efficiently executed by the 
underlying phyisical machine, even if the compiler produces 
native CPU opcodes, then I think that is not fully native.


A VM is just a conceptual machine. Although we tend to use the 
term in a more restricted way, x86 and x64 are also VMs (which a 
microcoded CPU does not actually implement in hardware!)

Re: Why I chose D over Ada and Eiffel


Yes and no.
While UTF-8 almost always is the most memory efficient 
representation of anything beyond ASCII it does have a property 
that can be troublesome a times, the difference between length 
and size of a string, i.e. the number of characters vs. the 
number of bytes used.


---

As for another issue I'm getting more and more disappointed: 
generics.


To put (my mind) bluntly, D does *not* support generics but 
rather went into the same ugly trap C++ went into, albeit D 
handles the situation way more elegantly.


Forgive me seeming harsh here but I just wrote it in the D gui 
thread: Any really great solution needs a solid philosophy and 
very profound thinking and consistency - and here D failed 
bluntly (in my minds eye).


With all due respect: Templates are an editors job, not a 
compilers.
Yes, templates offer some gadgets beyond simple replacement but 
basically they are just a comfort thingy, relieving the 
programmer from typing.


That, however, was *not* the point about generics. They are about 
implementing algorithms independent of data types (as far as 
possible).


Now, I'm looking around at mixins and interfaces in order to 
somehow makeshift some kind of a halfway reasonable generics 
mechanism. Yuck!


Well, maybe it's my fault. Maybe I was foolish to hope for 
something like Eiffel but more pragmatically useful and useable, 
more C style and way better documented. What I seem to have found 
with D is a *very nice* and *way better* and considerably more 
useful kind of C++.


Why aren't real generics there? I mean it's not that high tech or 
hard to implement (leaving aside macho bla bla like It'd break 
the ranges system).


why not something like

generic min(T:comparable) { // works only with comparable 
types/classes

  // min magic
}

This could then at *run time* work with anything that met the 
spec for comparable which basically came down to anything that 
offers equ and gt (and not).


On a sidenote: It seems we are somehow trapped in between two 
worlds, the theoreticians and the pragmatics. Walter and his 
colleagues have created an astonishingly beautiful beast coming 
from pure pragmatic engineering, while e.g. Prof. Meyer has 
created a brilliant system that just happens to be factually 
unuseable for the majority of developers (and be it only because 
hardly anyone will spend some 1.000$ to get started with Eiffel).
It's as if one side a purely as engineers while the other side 
just didn't care sh*t about their stuff being useable and useful.


My sincere apologies if I happened to offend anyone; that was 
definitely not my intention.

Re: Why I chose D over Ada and Eiffel

2013-08-20 Thread QAston


On Tuesday, 20 August 2013 at 16:40:21 UTC, Ramon wrote:

Yes and no.
While UTF-8 almost always is the most memory efficient 
representation of anything beyond ASCII it does have a property 
that can be troublesome a times, the difference between length 
and size of a string, i.e. the number of characters vs. the 
number of bytes used.


---

As for another issue I'm getting more and more disappointed: 
generics.


To put (my mind) bluntly, D does *not* support generics but 
rather went into the same ugly trap C++ went into, albeit D 
handles the situation way more elegantly.


Forgive me seeming harsh here but I just wrote it in the D gui 
thread: Any really great solution needs a solid philosophy and 
very profound thinking and consistency - and here D failed 
bluntly (in my minds eye).


With all due respect: Templates are an editors job, not a 
compilers.
Yes, templates offer some gadgets beyond simple replacement but 
basically they are just a comfort thingy, relieving the 
programmer from typing.


That, however, was *not* the point about generics. They are 
about implementing algorithms independent of data types (as far 
as possible).


Now, I'm looking around at mixins and interfaces in order to 
somehow makeshift some kind of a halfway reasonable generics 
mechanism. Yuck!


Well, maybe it's my fault. Maybe I was foolish to hope for 
something like Eiffel but more pragmatically useful and 
useable, more C style and way better documented. What I seem to 
have found with D is a *very nice* and *way better* and 
considerably more useful kind of C++.


Why aren't real generics there? I mean it's not that high tech 
or hard to implement (leaving aside macho bla bla like It'd 
break the ranges system).


why not something like

generic min(T:comparable) { // works only with comparable 
types/classes

  // min magic
}

This could then at *run time* work with anything that met the 
spec for comparable which basically came down to anything 
that offers equ and gt (and not).


Interfaces offer runtime resolution:

interface Comparable
{

}
void doStuff(Comparable c)
{
}
will work with anything that meets the specs for comparable.

For compile time resolution you can do this

Re: Why I chose D over Ada and Eiffel

2013-08-20 Thread QAston


On Tuesday, 20 August 2013 at 16:49:35 UTC, QAston wrote:

On Tuesday, 20 August 2013 at 16:40:21 UTC, Ramon wrote:

Yes and no.
While UTF-8 almost always is the most memory efficient 
representation of anything beyond ASCII it does have a 
property that can be troublesome a times, the difference 
between length and size of a string, i.e. the number of 
characters vs. the number of bytes used.


---

As for another issue I'm getting more and more disappointed: 
generics.


To put (my mind) bluntly, D does *not* support generics but 
rather went into the same ugly trap C++ went into, albeit D 
handles the situation way more elegantly.


Forgive me seeming harsh here but I just wrote it in the D gui 
thread: Any really great solution needs a solid philosophy and 
very profound thinking and consistency - and here D failed 
bluntly (in my minds eye).


With all due respect: Templates are an editors job, not a 
compilers.
Yes, templates offer some gadgets beyond simple replacement 
but basically they are just a comfort thingy, relieving the 
programmer from typing.


That, however, was *not* the point about generics. They are 
about implementing algorithms independent of data types (as 
far as possible).


Now, I'm looking around at mixins and interfaces in order to 
somehow makeshift some kind of a halfway reasonable generics 
mechanism. Yuck!


Well, maybe it's my fault. Maybe I was foolish to hope for 
something like Eiffel but more pragmatically useful and 
useable, more C style and way better documented. What I seem 
to have found with D is a *very nice* and *way better* and 
considerably more useful kind of C++.


Why aren't real generics there? I mean it's not that high tech 
or hard to implement (leaving aside macho bla bla like It'd 
break the ranges system).


why not something like

generic min(T:comparable) { // works only with comparable 
types/classes

 // min magic
}

This could then at *run time* work with anything that met the 
spec for comparable which basically came down to anything 
that offers equ and gt (and not).


Interfaces offer runtime resolution:

interface Comparable
{

}
void doStuff(Comparable c)
{
}
will work with anything that meets the specs for comparable.

For compile time resolution you can do this
sorry, I missclicked and then unintentionally posted this 
unfinished by Send keyboard shortcut :(

Re: Why I chose D over Ada and Eiffel


On Tuesday, 20 August 2013 at 16:40:21 UTC, Ramon wrote:

...


You are completely right - templates are not generics. They are, 
ironically, much more generic and are to solve quite a simple 
problem - copy-paste, in variety of forms.


If you think it is better to have an IDE to generate boilerplate 
instead of compiler, I can assure you, finding supporters in this 
community will be quite hard.


Insisting on the idea that implementing generic data types using 
run-time polymorphism costs is the True Way won't help either.


Honestly, I will never use any language that implies polymorphic 
design for stuff like container. Not of my free will at least. 
And every time I remember that boxing stuff in Java I have 
nightmares.


You want polymorphic approach - you have tools to implement it. 
Interfaces, classes, suit yourself. But, please, don't try to fix 
what is not broken.

Re: Possible solution to template bloat problem?


I'm afraid the issue is bigger.

One major criterion, for instance, is the basic question how we 
attribute weights to the involved entities.


C had a clear background. There was a new system (PDP11) and a 
need to use it. Memory was little and strongly limited, the 
typical use was quite modest (considerably less than what we 
today have on our mobile phones), processor power and capability 
was very low and very expensive, etc.


This, ladies and gentleman, is quite simple not anymore and 
adequate approach.


Don't get me wrong, I'm not on the side of the other extreme 
(Who cares about processor time and memory). But the world has 
very considerably changed and so has computing. Features that 
would have seemd miraculous in 1970 are low standard today and - 
very importantly - the whole world had very considerably gained 
in complexity.


If I need to programm a MPC430 or even an STM32F4, I'll use C, 
period. There *is* a solution for jobs with very tight 
constraints, we just don't need a new language for that.


If, however, I have to design and build a solution that works on 
different OSes incl. mobile phones and spans over a large network 
then I won't use C.


Furthermore, we have seen again and again how unreliable humans 
are at certain jobs. Just think virus,buffer overflow and a 
gazillion of other problems stemming from two reasons, a) lack of 
professionality and b) lack of perfection, where perfection is 
very much dependant on working tediously diligently and 
stubbornly (in other words, somethings that computers are *way* 
better at than humans).


Templates just don't cut it, period. Templates are 
ultra-yesteryear and proven to be troublesome, no matter how 
smartly you implement them. It's just not acceptable that a 
language in 2013 (in that regard) doesn't offer dimensionally 
more and better than what I could do with Brief or the like in 
1985.


So: Are D templates ugly loat? Yes, sure. Do I care? No, not at 
all. Why should I complain about D being unsatisfying as an 
editor?

Re: Possible solution to template bloat problem?


On Tuesday, 20 August 2013 at 16:59:00 UTC, Ramon wrote:

I'm afraid the issue is bigger.


Your insight about variety of modern programming language 
applications is extremely limited. If you are willing to 
introduce random runtime costs for nothing, there are lot of 
other awesome languages that can satisfy your needs.


As someone who does not want to write embedded'ish code in C 
anymore (and hopes to drag D there eventually) I am dangerously 
close to hating you.

Re: Possible solution to template bloat problem?


On Tuesday, 20 August 2013 at 17:05:21 UTC, Dicebot wrote:

On Tuesday, 20 August 2013 at 16:59:00 UTC, Ramon wrote:

I'm afraid the issue is bigger.


Your insight about variety of modern programming language 
applications is extremely limited. If you are willing to 
introduce random runtime costs for nothing, there are lot of 
other awesome languages that can satisfy your needs.


As someone who does not want to write embedded'ish code in C 
anymore (and hopes to drag D there eventually) I am dangerously 
close to hating you.


And that shows. Well, if that fits your definition of 
professional, so be it.


To avoid misunderstandings: I still like D and think that it's a 
great language/solution. I still see very attractive points. I 
still think that even templates can be attractive and are way 
better done in D than in C++.


I just don't agree that writing generics in the brochure and 
actually delivering templates is a good thing. And I happen to 
think that real generics are a very good thing.


Nevertheless, feel free to hate me and to get closer to ad 
hominems. I even promise to *not* consider your attitude to in 
any way reflect D's (or their creators) ;-)

Re: Why I chose D over Ada and Eiffel


On Tuesday, 20 August 2013 at 16:49:35 UTC, QAston wrote:

Interfaces offer runtime resolution:

interface Comparable
{

}
void doStuff(Comparable c)
{
}
will work with anything that meets the specs for comparable.

For compile time resolution you can do this


Thanks QAston for your constructive and helpful suggestion. 
Actually this is more or less the approach that I'm following 
(researching for the time being).


Actually I assume that Prof. Meyer was at that point at some 
time, too. He just happened, so it seems, to have figured out a 
way to do polymorphism right and painfree. Pragmatically this 
(your suggestion) pretty closely matches how one approaches it in 
Eiffel (but don't tell Prof. Meyer! He'll probably vehemently 
elaborate on theory *g).


Whatever, that's basically what I wanted. Although I have to 
lament somewhat that D's doc (as far as I know) doesn't point 
that out clearly.


Thanks.

Re: Ideas for a brand new widget toolkit


On 2013-08-20 15:30, Adam D. Ruppe wrote:


I'm about halfway to where I want to be with this now. After making the
Windows impl good and the X impl barely working, I'll go back and see
about making the X one slightly prettier and better functioning, but my
emphasis is still on small size so don't expect too much. (One option
would be to do GTK similarly like Windows as an option for nicer X
version.)


So no port for Mac OS X in sight? No X doesn't count.

--
/Jacob Carlborg

Re: When compiling multiple source files


On 2013-08-20 15:35, Timon Gehr wrote:


I was under the impression that this is a limitation of DMD and will be
fixed, right?


I think they (Walter, Don, possibly others) are working on it. CTFE 
apparently does unnecessary copying as well.


--
/Jacob Carlborg

Re: Why I chose D over Ada and Eiffel


On 8/20/2013 7:30 AM, H. S. Teoh wrote:

Well, I was referring to languages and systems invented today. Obviously
there is still a large amount of legacy code that can't handle Unicode
yet, but any new language or new system invented today has no excuse to
not support Unicode.


Even back in 1999 when I started with D, it was obvious that it had to be 
Unicode front to back.

Re: Why I chose D over Ada and Eiffel


On 8/20/2013 7:21 AM, Joseph Rushton Wakeling wrote:

On 20/08/13 00:00, Walter Bright wrote:

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.


On that note -- I was chatting with a (very functional- and Lisp-oriented)
friend about D and, when ranges were mentioned, he immediately connected it with
Clojure's concept of sequences: http://clojure.org/sequences

Does anyone know the history/relationship here between these and D's ranges? Was
it a direct influence from D, or convergent evolution -- and can anyone comment
on the relative merits of the D vs. Clojure approaches?


This style of programming has been around at least since the Unix pipes and 
filters model. It also appears as C#'s LINQ programming style.


However, LINQ and Clojure were not direct influences on D's ranges.

Re: Why I chose D over Ada and Eiffel


On 8/20/2013 3:52 AM, Dicebot wrote:

On Tuesday, 20 August 2013 at 07:21:43 UTC, Walter Bright wrote:

On 8/20/2013 12:02 AM, Jacob Carlborg wrote:

On 2013-08-20 00:14, Walter Bright wrote:


Note the holding back of std.serialization until it has full support for
ranges.


I guess we won't see any std.serialization then. It cannot fully support ranges
until the backend does, in this case std.xml.


Why not?


As far as I understand the problem, current std.xml implementation does not
allow to implement lazy range-based archiver in terms of Phobos.

Not however, that I have not delayed voting until std.serialization gets full
support of ranges - only until its API gets support for ranges such that
implementation can be later added in a non-breaking way, for example, with new
archivers.

There is some small discussion on this topic. Unfortunately I had not take the
time to study source deep enough to state what reasonable requirements can be
here (ones that won't require Jacob to re-implelement half of the package) but I
am definitely going to.


Sounds reasonable. Thanks for following up on this.

Re: Possible solution to template bloat problem?