Re: Anonymous function syntax

[Max Klyga]

Actually Scala doesn't need type declarations in labmda literals. Most 
of the time argument types are infered. It would be awesome if D 
infered argument types for labdas too.

Also Java 8 adopted the same lambda syntax as Scala and C#.

To add a few things to your list:

Nemerle
   fun (x, y) { x + y }
   (x, y) => x + y

Scala and Nemerle supports placeholder lambda syntax
   _ + _

Scheme
   (lambda (x y) (+ x y))

Smalltalk
   [ :x :y | x + y ]

ML/Ocaml/F#
   fun x y -> x + y

Ruby has a whole zoo of syntaxes
   {|x, y| x + y }
   ->(x, y) { x + y }
   do |x, y| x + y end

Groovy
   { x, y -> x + y }

So "(args) => body" is the most common syntax now

Re: __restrict, architecture intrinsics vs asm, consoles, and other

[Don]

On 22.09.2011 05:24, a wrote:

How would one do something like this without intrinsics (the code is c++ using
gcc vector extensions):


[snip]
At present, you can't do it without ultimately resorting to inline asm. 
But, what we've done is to move SIMD into the machine model: the D 
machine model assumes that float[4] + float[4] is a more efficient 
operation than a loop.
Currently, only arithmetic operations are implemented, and on DMD at 
least, they're still not proper intrinsics. So in the long term it'll be 
possible to do it directly, but not yet.


At various times, several of us have implemented 'swizzle' using CTFE, 
giving you a syntax like:


float[4] x, y;
x[] = y[].swizzle!"cdcd"();
// x[0]=y[2], x[1]=y[3], x[2]=y[2], x[3]=y[3]

which compiles to a single shufps instruction.

That "cdcd" string is really a tiny DSL: the language consists of four 
characters, each of which is a, b, c, or d.


A couple of years ago I made a DSL compiler for BLAS1 operations. It was 
capable of doing some pretty wild stuff, even then. (The DSL looked like 
normal D code).
But the compiler has improved enormously since that time. It's now 
perfectly feasible to make a DSL for the SIMD operations you need.


The really nice thing about this, compared to normal asm, is that you 
have access to the compiler's symbol table. This lets you add 
compile-time error messages, for example.


A funny thing about this, which I found after working on the DMD 
back-end, is that is MUCH easier to write an optimizer/code generator in 
a DSL in D, than in a compiler back-end.




template
struct Fft
{
   typedef typename V::T T;
   typedef typename V::vec vec;
   static const int VecSize = V::Size;

...

   template
   static NOINLINE void fft_pass_interleaved(
 vec * __restrict pr,
 vec *__restrict pi,
 vec *__restrict pend,
 T *__restrict table)
   {
 for(; pr<  pend; pr += 2, pi += 2, table += 2*Interleaved)
 {
   vec tmpr, ti, ur, ui, wr, wi;
   V::template expandComplexArrayToRealImagVec(table, wr, wi);
   V::template deinterleave(pr[0],pr[1], ur, tmpr);
   V::template deinterleave(pi[0],pi[1], ui, ti);
   vec tr = tmpr*wr - ti*wi;
   ti = tmpr*wi + ti*wr;
   V::template interleave(ur + tr, ur - tr, pr[0], pr[1]);
   V::template interleave(ui + ti, ui - ti, pi[0], pi[1]);
 }
   }

...

Here vector elements need to be shuffled around when they are loaded and stored.
This is platform dependent and cannot be expressed through vector operations
(or gcc vector extensions).  Here I abstracted platform dependent functionality
in member functions of  V, which are implemented using intrinsics.  The assembly
generated for SSE single precision and Interleaved=4 is:

  
<_ZN3FftI6SSEVecIfEE20fft_pass_interleavedILi4EEEvPDv4_fS5_S5_Pf>:
0:  48 39 d7cmp%rdx,%rdi
3:  0f 83 9c 00 00 00   jae
a5<_ZN3FftI6SSEVecIfEE20fft_pass_interleavedILi4EEEvPDv4_fS5_S5_Pf+0xa5>
9:  0f 1f 80 00 00 00 00nopl   0x0(%rax)
   10:  0f 28 19movaps (%rcx),%xmm3
   13:  0f 28 41 10 movaps 0x10(%rcx),%xmm0
   17:  48 83 c1 20 add$0x20,%rcx
   1b:  0f 28 f3movaps %xmm3,%xmm6
   1e:  0f 28 2fmovaps (%rdi),%xmm5
   21:  0f c6 d8 dd shufps $0xdd,%xmm0,%xmm3
   25:  0f c6 f0 88 shufps $0x88,%xmm0,%xmm6
   29:  0f 28 e5movaps %xmm5,%xmm4
   2c:  0f 28 47 10 movaps 0x10(%rdi),%xmm0
   30:  0f 28 4e 10 movaps 0x10(%rsi),%xmm1
   34:  0f c6 e0 88 shufps $0x88,%xmm0,%xmm4
   38:  0f c6 e8 dd shufps $0xdd,%xmm0,%xmm5
   3c:  0f 28 06movaps (%rsi),%xmm0
   3f:  0f 28 d0movaps %xmm0,%xmm2
   42:  0f c6 c1 dd shufps $0xdd,%xmm1,%xmm0
   46:  0f c6 d1 88 shufps $0x88,%xmm1,%xmm2
   4a:  0f 28 cdmovaps %xmm5,%xmm1
   4d:  0f 28 f8movaps %xmm0,%xmm7
   50:  0f 59 cemulps  %xmm6,%xmm1
   53:  0f 59 fbmulps  %xmm3,%xmm7
   56:  0f 59 c6mulps  %xmm6,%xmm0
   59:  0f 59 ddmulps  %xmm5,%xmm3
   5c:  0f 5c cfsubps  %xmm7,%xmm1
   5f:  0f 58 c3addps  %xmm3,%xmm0
   62:  0f 28 dcmovaps %xmm4,%xmm3
   65:  0f 5c d9subps  %xmm1,%xmm3
   68:  0f 58 ccaddps  %xmm4,%xmm1
   6b:  0f 28 e1movaps %xmm1,%xmm4
   6e:  0f 15 cbunpckhps %xmm3,%xmm1
   71:  0f 14 e3unpcklps %xmm3,%xmm4
   74:  0f 29 4f 10 movaps %xmm1,0x10(%rdi)
   78:  0f 28 camovaps %xmm2,%xmm1
   7b:  0f 29 27movaps %xmm4,(%rdi)
   7e:  0f 5c c8subps  %xmm0,%xmm1
   81:  48 83 c7 20 add$0x20,%rdi
   85:  0f 58 c2addps  %xmm2,%xmm0
   88:  0f 28 d0movaps %xmm0,%xmm2
   8b:  

thoughts on immutability in D

[Andrei Alexandrescu]

The initial submission got junked so I resubmitted:

http://www.reddit.com/r/programming/comments/knn5p/thoughts_on_immutability_in_d/


Andrei

Re: __restrict, architecture intrinsics vs asm, consoles, and other stuff

[Benjamin Thaut]

Am 22.09.2011 02:38, schrieb Walter Bright:

nsightly vector classes in C++, but fortunately using vendor
specific compiler intrinsics usually leads to decent code
generation. I can currently imagine an equally ugly (possibly worse)
hardware vector library in D, if it's even possible. But perhaps
I've missed something here?


Your C++ vector code should be amenable to translation to D, so that
effort of yours isn't lost, except that it'd have to be in inline asm
rather than intrinsics.


I recently tried that, and I couldn't do it because D has no way of 
aligning structs on the stack. Manually allocating the neccessary 
aligned memroy is also not always possible because it can not be done 
for compiler temporary variables:


vec4 v1 = func1();
vec4 v2 = func2();
vec4 result = (v1 + v2) * 0.5f;

Even if I manually allocate v1,v2 and result, the temporary variable 
that the compiler uses to compute the expression might be unaligned.
That is a total killer for SSE optimizations because you can not hide 
them away.


Does DMC++ have __declspec(align(16)) support?

--
Kind Regards
Benjamin Thaut

Re: The Strange Loop conference

[Don]

On 21.09.2011 22:32, Sean Kelly wrote:

On Sep 21, 2011, at 12:59 PM, Andrei Alexandrescu wrote:


On 9/21/11 12:59 PM, bearophile wrote:

Andrei Alexandrescu:


which has enjoyed moderate audience and success. I uploaded the
slides at http://erdani.com/d/generic-programming-galore.pdf and
the video may be available soon.


In future talks I suggest to show some downsides too, like explaining
how much memory uses the D RE engine, how hard are to write, read,
modify and debug text-based mixins like the bitfields, etc.


I did mention the downsides in the talk: memory consumption during CTFE and the 
compiler's inability to explain why a template didn't match.


If DMD cleaned up after itself, the memory consumption issue would be far less 
significant though.  Perhaps DMD could be fixed up to the point where GC could 
be enabled?  I recall the code being there, but that there were issues with 
turning it on.


The CTFE memory consumption and slowness is not a gc issue.
It's copy-on-write:
http://d.puremagic.com/issues/show_bug.cgi?id=6498
I know how to fix this.

Re: __restrict, architecture intrinsics vs asm, consoles, and other stuff

[Iain Buclaw]

== Quote from Manu (turkey...@gmail.com)'s article
> Hello D community.
> I've been reading a lot about D lately. I have known it existed for
> ages, but for some reason never even took a moment to look into it.
> The more I looked into it, the more I realise, this is the language
> I want. C(/C++) has been ruined, far beyond salvation. D seems to be
> the reboot that it desperately needs.
> Anyway, I work in the games industry, 10 years in cross platform
> console games at major studios. Sadly, I don't think Microsoft,
> Sony, Nintendo, Apple, Google (...maybe google) will support D any
> time soon, but I've started some after-hours game projects to test D
> in a some real gamedev environments.
> So far I have these (critical) questions.
> Pointer aliasing... C implementations uses a non-standard __restrict
> keyword to state that a given pointer will not be aliased by any
> other pointer. This is critical in some pieces of code to eliminate
> redundant loads and stores, particularly important on RISC
> architectures like PPC.
> How does D address pointer aliasing? I can't imagine the compiler
> has any way to detect that pointer aliasing is not possible in
> certain cases, many cases are just far too complicated. Is there a
> keyword? Or plans? This is critical for realtime performance.
> C implementations often use compiler intrinsics to implement
> architecture provided functionality rather than inline asm, the
> reason is that the intrinsics allow the compiler to generate better
> code with knowledge of the context. Inline asm can't really be
> transformed appropriately to suit the context in some situations,
> whereas intrinsics operate differently, and run vendor specific
> logic to produce the code more intelligently.
> How does D address this? What options/possibilities are available to
> the language? Hooks for vendors to implement intrinsics for custom
> hardware?

The DMD compiler has some basic intrinsics, other compilers build upon this 
using
their own backends. ie: GCC has hundreds of builtins, including some target
builtins where intrinsic types are mappable to D types (__float80 ->.real).

> Is the D assembler a macro assembler? (ie, assigns registers
> automatically and manage loads/stores intelligently?) I haven't seen
> any non-x86 examples of the D assembler, and I think it's fair to
> say that x86 is the single most unnecessary architecture to write
> inline assembly that exists. Are there PowerPC or ARM examples
> anywhere?
> As an extension from that, why is there no hardware vector support
> in the language? Surely a primitive vector4 type would be a sensible
> thing to have?
> Is it possible in D currently to pass vectors to functions by value
> in registers? Without an intrinsic vector type, it would seem
> impossible.
> In addition to that, writing a custom Vector4 class to make use of
> VMX, SSE, ARM VFP, PSP VFPU, MIPS 'Vector Units', SH4 DR regs, etc,
> wrapping functions around inline asm blocks is always clumsy and far
> from optimal. The compiler (code generator and probably the
> optimiser) needs to understand the concepts of vectors to make good
> use of the hardware.
> How can I do this in a nice way in D? I'm long sick of writing
> unsightly vector classes in C++, but fortunately using vendor
> specific compiler intrinsics usually leads to decent code
> generation. I can currently imagine an equally ugly (possibly worse)
> hardware vector library in D, if it's even possible. But perhaps
> I've missed something here?

I would imagine it should now be possible to use GCC vector builtins with the 
GDC
compiler. Given that I manage to get round to turning these routines on though. 
:~)

> I'd love to try out D on some console systems. Fortunately there are
> some great home-brew scenes available for a bunch of slightly older
> consoles; PSP/PS2 (MIPS), XBox1 (embedded x86), GameCube/Wii (PPC),
> Dreamcast (SH4). They all have GCC compilers maintained by the
> community. How difficult will it be to make GDC work with those
> toolchains? Sadly I know nothing about configuring GCC, so sadly I
> can't really help here.
> What about Android (or iPhone, but apple's 'x-code policy' prevents
> that)? I'd REALLY love to write an android project in D... the
> toolchain is GCC, I see no reason why it shouldn't be possible to
> write an android app if an appropriate toolchain was available?
> Sorry it's a bit long, thanks for reading this far!
> I'm looking forward to a brighter future writing lots of D code :P
> But I need to know basically all these questions are addressed
> before I could consider it for serious commercial game dev.

Someone has recently confirmed D working just fine on the Alpha platform.  For 
D2,
your biggest showstopper is the runtime library.  There are many gaps to fill to
port druntime to your preferred architecture.

Regards

Re: D User Group (DUG) in London - who would be interested in attending?

[Iain Buclaw]

== Quote from Moritz Warning (moritzwarn...@web.de)'s article
> On Mon, 19 Sep 2011 11:21:04 +, Iain Buclaw wrote:
> > Some of us Great British IRC users in #d have been discussing this for
> > some time now, but now we'd like to see this organised and put into
> > fruition. :)
> >
> What do you plan?
> A nice evening in a pub or something bigger?

I would have set my sights on a nice evening in a pub. However, will need to 
talk
this out first to see if we want to get some events going on.


I'll be there for the beer. :o)

Re: __restrict, architecture intrinsics vs asm, consoles, and other

[a]

How would one do something like this without intrinsics (the code is c++ using 
gcc vector extensions): 

template 
struct Fft 
{
  typedef typename V::T T;
  typedef typename V::vec vec;
  static const int VecSize = V::Size;

...

  template 
  static NOINLINE void fft_pass_interleaved(
vec * __restrict pr, 
vec *__restrict pi, 
vec *__restrict pend, 
T *__restrict table)  
  {
for(; pr < pend; pr += 2, pi += 2, table += 2*Interleaved)
{
  vec tmpr, ti, ur, ui, wr, wi;
  V::template expandComplexArrayToRealImagVec(table, wr, wi);
  V::template deinterleave(pr[0],pr[1], ur, tmpr);
  V::template deinterleave(pi[0],pi[1], ui, ti);
  vec tr = tmpr*wr - ti*wi;
  ti = tmpr*wi + ti*wr;
  V::template interleave(ur + tr, ur - tr, pr[0], pr[1]);
  V::template interleave(ui + ti, ui - ti, pi[0], pi[1]);
}
  }

...

Here vector elements need to be shuffled around when they are loaded and 
stored. 
This is platform dependent and cannot be expressed through vector operations 
(or gcc vector extensions).  Here I abstracted platform dependent functionality 
in member functions of  V, which are implemented using intrinsics.  The 
assembly 
generated for SSE single precision and Interleaved=4 is:

  
<_ZN3FftI6SSEVecIfEE20fft_pass_interleavedILi4EEEvPDv4_fS5_S5_Pf>:
   0:   48 39 d7cmp%rdx,%rdi
   3:   0f 83 9c 00 00 00   jaea5 
<_ZN3FftI6SSEVecIfEE20fft_pass_interleavedILi4EEEvPDv4_fS5_S5_Pf+0xa5>
   9:   0f 1f 80 00 00 00 00nopl   0x0(%rax)
  10:   0f 28 19movaps (%rcx),%xmm3
  13:   0f 28 41 10 movaps 0x10(%rcx),%xmm0
  17:   48 83 c1 20 add$0x20,%rcx
  1b:   0f 28 f3movaps %xmm3,%xmm6
  1e:   0f 28 2fmovaps (%rdi),%xmm5
  21:   0f c6 d8 dd shufps $0xdd,%xmm0,%xmm3
  25:   0f c6 f0 88 shufps $0x88,%xmm0,%xmm6
  29:   0f 28 e5movaps %xmm5,%xmm4
  2c:   0f 28 47 10 movaps 0x10(%rdi),%xmm0
  30:   0f 28 4e 10 movaps 0x10(%rsi),%xmm1
  34:   0f c6 e0 88 shufps $0x88,%xmm0,%xmm4
  38:   0f c6 e8 dd shufps $0xdd,%xmm0,%xmm5
  3c:   0f 28 06movaps (%rsi),%xmm0
  3f:   0f 28 d0movaps %xmm0,%xmm2
  42:   0f c6 c1 dd shufps $0xdd,%xmm1,%xmm0
  46:   0f c6 d1 88 shufps $0x88,%xmm1,%xmm2
  4a:   0f 28 cdmovaps %xmm5,%xmm1
  4d:   0f 28 f8movaps %xmm0,%xmm7
  50:   0f 59 cemulps  %xmm6,%xmm1
  53:   0f 59 fbmulps  %xmm3,%xmm7
  56:   0f 59 c6mulps  %xmm6,%xmm0
  59:   0f 59 ddmulps  %xmm5,%xmm3
  5c:   0f 5c cfsubps  %xmm7,%xmm1
  5f:   0f 58 c3addps  %xmm3,%xmm0
  62:   0f 28 dcmovaps %xmm4,%xmm3
  65:   0f 5c d9subps  %xmm1,%xmm3
  68:   0f 58 ccaddps  %xmm4,%xmm1
  6b:   0f 28 e1movaps %xmm1,%xmm4
  6e:   0f 15 cbunpckhps %xmm3,%xmm1
  71:   0f 14 e3unpcklps %xmm3,%xmm4
  74:   0f 29 4f 10 movaps %xmm1,0x10(%rdi)
  78:   0f 28 camovaps %xmm2,%xmm1
  7b:   0f 29 27movaps %xmm4,(%rdi)
  7e:   0f 5c c8subps  %xmm0,%xmm1
  81:   48 83 c7 20 add$0x20,%rdi
  85:   0f 58 c2addps  %xmm2,%xmm0
  88:   0f 28 d0movaps %xmm0,%xmm2
  8b:   0f 15 c1unpckhps %xmm1,%xmm0
  8e:   0f 14 d1unpcklps %xmm1,%xmm2
  91:   0f 29 46 10 movaps %xmm0,0x10(%rsi)
  95:   0f 29 16movaps %xmm2,(%rsi)
  98:   48 83 c6 20 add$0x20,%rsi
  9c:   48 39 facmp%rdi,%rdx
  9f:   0f 87 6b ff ff ff   ja 10 
<_ZN3FftI6SSEVecIfEE20fft_pass_interleavedILi4EEEvPDv4_fS5_S5_Pf+0x10>
  a5:   f3 c3   repz retq 

Would something like that be possible with D inline assembly or would there be 
additional loads and stores for each call of V::interleave, V::deinterleave 
and V::expandComplexArrayToRealImagVec?

Re: Why do we have transitive const, again?

[Jesse Phillips]

On Wed, 21 Sep 2011 10:15:31 -0700, Mehrdad wrote:

> I can't find the thread, but I remember someone (bearophile?) mentioned
> that the reason we have transitive const is to support purity.
> 
> I don't think I understand why this is necessary, though -- could
> someone please explain why we have transitive const, and what problems
> it fixes?
> 
> Thanks!

I came across this blog earlier, it may hold the answers you seek:

http://www.reddit.com/tb/kkwch

"One of the core difficulties in concurrent programming is trying to 
avoid the simultaneous reading and writing of data. Like with functional 
programming, concurrent programming is a lot easier when data can't 
change -- if you have no writes then you can't possibly have 
simultaneously reading and writing. However, unlike functional 
programming, logical const just doesn't cut it. If you were to give a 
reference to an instance of my Matrix class to two threads, and ask them 
both to compute the determinant then you could end up with an ugly race 
condition due to the memory writes in the caching mechanism. Here, 
physical immutability really does matter."

Re: Anonymous function syntax

[Jesse Phillips]

On Wed, 21 Sep 2011 18:29:34 -0400, bearophile wrote:

> Walter Bright:
> 
>> D
>>  (a,b) { return a + b; }
> 
> In D to define a true lambda you need types too: auto f = (int a,int b){
> return a + b; };

This is true of C# too and I think is appropriate to mention, though it 
can take the destination type into account when doing inference.

> For D I think I'd like a syntax like: { int a, int b => a + b }
> That in some cases becomes just:
> { a,b => a + b }

I'd rather the C which is basically the same as D already.

Re: __restrict, architecture intrinsics vs asm, consoles, and other stuff

[Walter Bright]

On 9/21/2011 3:55 PM, Manu wrote:

Pointer aliasing... C implementations uses a non-standard __restrict
keyword to state that a given pointer will not be aliased by any
other pointer. This is critical in some pieces of code to eliminate
redundant loads and stores, particularly important on RISC
architectures like PPC.
How does D address pointer aliasing? I can't imagine the compiler
has any way to detect that pointer aliasing is not possible in
certain cases, many cases are just far too complicated. Is there a
keyword? Or plans? This is critical for realtime performance.


D doesn't have __restrict. I'm going to argue that it is unnecessary. AFAIK, 
__restrict is most used in writing vector operations. D, on the other hand, has 
a dedicated vector operation syntax:


  a[] += b[] * c;

where a[] and b[] are required to not be overlapping, hence enabling 
parallelization of the operation.




C implementations often use compiler intrinsics to implement
architecture provided functionality rather than inline asm, the
reason is that the intrinsics allow the compiler to generate better
code with knowledge of the context. Inline asm can't really be
transformed appropriately to suit the context in some situations,
whereas intrinsics operate differently, and run vendor specific
logic to produce the code more intelligently.
How does D address this? What options/possibilities are available to
the language? Hooks for vendors to implement intrinsics for custom
hardware?


D does have some intrinsics, like sin() and cos(). They tend to get added on a 
strictly as-needed basis, not a speculative one.


D has no current intention to replace the inline assembler with intrinsics.

As for custom intrinsics, Don Clugston wrote an amazing piece of demonstration D 
code a while back that would take a string representing a floating point 
expression, and would literally compile it (using Compile Time Function 
Execution) and produce a string literal of inline asm functions, which were then 
compiled by the inline assembler.


So yes, it is entirely possible and practical for end users to write custom 
intrinsics.




Is the D assembler a macro assembler?


No. It's what-you-write-is-what-you-get.


(ie, assigns registers
automatically and manage loads/stores intelligently?)


No. It's intended to be a low level assembler for those who want to precisely 
control things.



I haven't seen
any non-x86 examples of the D assembler, and I think it's fair to
say that x86 is the single most unnecessary architecture to write
inline assembly that exists.


I enjoy writing x86 inline assembler :-)


Are there PowerPC or ARM examples anywhere?


The intention is for other CPU targets to employ the syntax used in their 
respective CPU manual datasheets.




As an extension from that, why is there no hardware vector support
in the language? Surely a primitive vector4 type would be a sensible
thing to have?


The language supports it now (see the aforementioned vector syntax), it's just 
that the vector code gen isn't done (currently it is just implemented using loops).



Is it possible in D currently to pass vectors to functions by value
in registers? Without an intrinsic vector type, it would seem
impossible.


Vectors (statically dimensioned arrays) are currently passed by value (unlike C 
or C++).



In addition to that, writing a custom Vector4 class to make use of
VMX, SSE, ARM VFP, PSP VFPU, MIPS 'Vector Units', SH4 DR regs, etc,
wrapping functions around inline asm blocks is always clumsy and far
from optimal. The compiler (code generator and probably the
optimiser) needs to understand the concepts of vectors to make good
use of the hardware.


Yes, I agree.


How can I do this in a nice way in D? I'm long sick of writing
unsightly vector classes in C++, but fortunately using vendor
specific compiler intrinsics usually leads to decent code
generation. I can currently imagine an equally ugly (possibly worse)
hardware vector library in D, if it's even possible. But perhaps
I've missed something here?


Your C++ vector code should be amenable to translation to D, so that effort of 
yours isn't lost, except that it'd have to be in inline asm rather than intrinsics.




I'd love to try out D on some console systems. Fortunately there are
some great home-brew scenes available for a bunch of slightly older
consoles; PSP/PS2 (MIPS), XBox1 (embedded x86), GameCube/Wii (PPC),
Dreamcast (SH4). They all have GCC compilers maintained by the
community. How difficult will it be to make GDC work with those
toolchains? Sadly I know nothing about configuring GCC, so sadly I
can't really help here.


I don't know much about GDC's capabilities.

Re: __restrict, architecture intrinsics vs asm, consoles, and other stuff

[Trass3r]

I haven't seen any non-x86 examples of the D assembler, and I think it's  
fair to

say that x86 is the single most unnecessary architecture to write
inline assembly that exists. Are there PowerPC or ARM examples
anywhere?


Well DMD only supports x86 including inline asm so that's the only thing  
that's tested.


You need to try LDC or GDC for most of the things you request.
http://dsource.org/projects/ldc/wiki/InlineAsmExpressions
https://bitbucket.org/goshawk/gdc/wiki/UserDocumentation#!extended-assembler


Some guys already managed to compile cross-compilers for ARM and ran some  
basic code on e.g. Nintendo DS.

For anything serious you would need to make druntime work though.

It's just nobody has done the dirty work yet.

Re: D on hackernews

[Timon Gehr]

On 09/22/2011 01:17 AM, Marco Leise wrote:

Am 21.09.2011, 16:24 Uhr, schrieb Andrei Alexandrescu
:


On 9/21/11 8:52 AM, Timon Gehr wrote:

On 09/21/2011 09:37 AM, bearophile wrote:

Andrei Alexandrescu:


http://hackerne.ws/item?id=3014861

Apparently we're still having a PR issue.


I think the Wikipedia D page needs to be rewritten, leaving 80-90% of
its space to D (meaning D2).



Yes, that is important. Wikipedia is usually the first place people go
looking for information, and much of the information given there is
horribly outdated/wrong and mostly only concerns.


Agreed. Does anyone volunteer for fixing D's Wikipedia page?

Andrei


Is anyone uninvolved enough to be objective and involved enough to know
what they write?
Timon, I think you are exaggerating a bit. It is not mostly only
concerns, but I agree they have bold headers, and other language pages
like Java or C++ lack this section entirely.


On 09/21/2011 04:33 PM, Timon Gehr wrote:
>> Yes, that is important. Wikipedia is usually the first place people go
>> looking for information, and much of the information given there is
>> horribly outdated/wrong and mostly only concerns.
>
> ... concerns [D1].

That was just a bad place to accidentally leave out a word. ;)
I agree that the article also contains some useful information.

Re: The Strange Loop conference

[bearophile]

Andrei Alexandrescu:

> Feel free to spare the patronizing part, it won't be missed.

I am sorry. I have full respect for Walter's and yours work.

Bye,
bearophile

Re: D on hackernews

[Marco Leise]

Am 21.09.2011, 16:24 Uhr, schrieb Andrei Alexandrescu  
:



On 9/21/11 8:52 AM, Timon Gehr wrote:

On 09/21/2011 09:37 AM, bearophile wrote:

Andrei Alexandrescu:


http://hackerne.ws/item?id=3014861

Apparently we're still having a PR issue.


I think the Wikipedia D page needs to be rewritten, leaving 80-90% of
its space to D (meaning D2).



Yes, that is important. Wikipedia is usually the first place people go
looking for information, and much of the information given there is
horribly outdated/wrong and mostly only concerns.


Agreed. Does anyone volunteer for fixing D's Wikipedia page?

Andrei


Is anyone uninvolved enough to be objective and involved enough to know  
what they write?
Timon, I think you are exaggerating a bit. It is not mostly only concerns,  
but I agree they have bold headers, and other language pages like Java or  
C++ lack this section entirely. Now it would certainly make people  
suspicious if the section disappeared over night. I would reduce the font  
weight of the headers in that section, remove the talk about UTF-8 string  
handling, at some point in time move the 'library split' issue to a  
historical section about D1. I think the focus on x86 is also a valid  
concern.


Here are some statistics I collected, for fun:

The Català version also says the following:
- It is unstable and unsuitable for production environments (version 0.140)

The Català and Galego version say:
- The only documentation is the official specification

The following languages are a direct translations of (or the source for)  
the English version. Maybe their authors can be contacted and are willing  
to update their language version after the change:

- Arabic
- Español
- Polski (not the exact same sections, probably translated from an older  
version)


The Italian version has the most impressive features list with 14 sections  
about characteristics!


The Latin version is blowing my mind, just because people who use a long  
dead language would write code in a new one that has to do with computers:


import tango.io.Console;

int main(char[][] args) {
Cout("salve munde!");
return 0;
}

Many language pages are hopelessly outdated, but speakers of 'minority'  
languages will look for an English article anyway.

Re: Anonymous function syntax

[Timon Gehr]

On 09/22/2011 12:47 AM, deadalnix wrote:

Le 22/09/2011 00:29, bearophile a écrit :

Walter Bright:


D
(a,b) { return a + b; }


In D to define a true lambda you need types too:
auto f = (int a,int b){ return a + b; };


If you leave types away, you in fact create a function template literal. 
Interestingly those only work for templates so far. I'd like them to 
work at other places, eg when the argument types are clear from the type 
signature of a function the delegate gets passed to.


void foo(int delegate(int)){}
void main(){
foo((a){return a;}); // this could work
}



For D I think I'd like a syntax like:
{ int a, int b => a + b }
That in some cases becomes just:
{ a,b => a + b }



Then you'd probably have map!{a => 2*a}(range);

That is very easy on the eyes. +1. What about:

void foo(int delegate(int)){}
void main(){
foo{a=>2*a}; // ok?
}

Is binary '{' worth spending like that?




That would be less readable for somebody coming from a C styled
language. Curly braces for body and parenthesis for arguments is
something very familiar.

This makes Javascript's and D's closures the most readable for somebody
having this background.


The delegates themselves are very readable indeed but they tend to screw 
up the readability of larger expressions that contain them. An alternate 
delegate syntax could help a great deal in these cases.

Re: Good publicity for D on heise/developer

[Nick Sabalausky]

"Tobias Pankrath"  wrote in message 
news:j5d0ku$1b62$1...@digitalmars.com...
>
> C++0xb

Hah, I see what you did there!

__restrict, architecture intrinsics vs asm, consoles, and other stuff

[Manu]

Hello D community.

I've been reading a lot about D lately. I have known it existed for
ages, but for some reason never even took a moment to look into it.
The more I looked into it, the more I realise, this is the language
I want. C(/C++) has been ruined, far beyond salvation. D seems to be
the reboot that it desperately needs.

Anyway, I work in the games industry, 10 years in cross platform
console games at major studios. Sadly, I don't think Microsoft,
Sony, Nintendo, Apple, Google (...maybe google) will support D any
time soon, but I've started some after-hours game projects to test D
in a some real gamedev environments.

So far I have these (critical) questions.

Pointer aliasing... C implementations uses a non-standard __restrict
keyword to state that a given pointer will not be aliased by any
other pointer. This is critical in some pieces of code to eliminate
redundant loads and stores, particularly important on RISC
architectures like PPC.
How does D address pointer aliasing? I can't imagine the compiler
has any way to detect that pointer aliasing is not possible in
certain cases, many cases are just far too complicated. Is there a
keyword? Or plans? This is critical for realtime performance.

C implementations often use compiler intrinsics to implement
architecture provided functionality rather than inline asm, the
reason is that the intrinsics allow the compiler to generate better
code with knowledge of the context. Inline asm can't really be
transformed appropriately to suit the context in some situations,
whereas intrinsics operate differently, and run vendor specific
logic to produce the code more intelligently.
How does D address this? What options/possibilities are available to
the language? Hooks for vendors to implement intrinsics for custom
hardware?
Is the D assembler a macro assembler? (ie, assigns registers
automatically and manage loads/stores intelligently?) I haven't seen
any non-x86 examples of the D assembler, and I think it's fair to
say that x86 is the single most unnecessary architecture to write
inline assembly that exists. Are there PowerPC or ARM examples
anywhere?

As an extension from that, why is there no hardware vector support
in the language? Surely a primitive vector4 type would be a sensible
thing to have?
Is it possible in D currently to pass vectors to functions by value
in registers? Without an intrinsic vector type, it would seem
impossible.
In addition to that, writing a custom Vector4 class to make use of
VMX, SSE, ARM VFP, PSP VFPU, MIPS 'Vector Units', SH4 DR regs, etc,
wrapping functions around inline asm blocks is always clumsy and far
from optimal. The compiler (code generator and probably the
optimiser) needs to understand the concepts of vectors to make good
use of the hardware.
How can I do this in a nice way in D? I'm long sick of writing
unsightly vector classes in C++, but fortunately using vendor
specific compiler intrinsics usually leads to decent code
generation. I can currently imagine an equally ugly (possibly worse)
hardware vector library in D, if it's even possible. But perhaps
I've missed something here?

I'd love to try out D on some console systems. Fortunately there are
some great home-brew scenes available for a bunch of slightly older
consoles; PSP/PS2 (MIPS), XBox1 (embedded x86), GameCube/Wii (PPC),
Dreamcast (SH4). They all have GCC compilers maintained by the
community. How difficult will it be to make GDC work with those
toolchains? Sadly I know nothing about configuring GCC, so sadly I
can't really help here.

What about Android (or iPhone, but apple's 'x-code policy' prevents
that)? I'd REALLY love to write an android project in D... the
toolchain is GCC, I see no reason why it shouldn't be possible to
write an android app if an appropriate toolchain was available?

Sorry it's a bit long, thanks for reading this far!
I'm looking forward to a brighter future writing lots of D code :P
But I need to know basically all these questions are addressed
before I could consider it for serious commercial game dev.

Re: Anonymous function syntax

[Andrei Alexandrescu]

On 9/21/11 5:29 PM, bearophile wrote:

Walter Bright:


D
  (a,b) { return a + b; }


In D to define a true lambda you need types too:
auto f = (int a,int b){ return a + b; };


No.

Andrei

Re: The Strange Loop conference

[Andrei Alexandrescu]

On 9/21/11 5:22 PM, bearophile wrote:

This is why I have asked for functions like amap/afilter in Phobos,
because in many situations in D you need an array instead of a lazy
range.


I don't think that was being asked.


Of course, if every function that accepts a range becomes a
template then you have the practical problem of managing the number
of template instantiations. Code bloat is still a real problem with
heavy template usage.


Haskell has used typeclasses to avoid this :-)


At the conference I discussed typeclasses at length with a Haskell 
connoisseur and he had to agree that D's template constraints are a 
suitable replacement, and also that template constraints can express 
requirements that type classes have difficulties with. This is because 
D's template constraints can involve several types simultaneously and 
can do arbitrary computations. (That's also what makes them less 
structured than typeclasses.)



Finally, map in Haskell just makes sense. You have a list of a's,
a function of 'a to b' and you get a list of b's out the other end.
It's simple, it's exactly what you want, and it just works. You
can't say the same in D.


I agree. That has two good consequences: - It makes sense for the
Haskell compiler too, so it is able to perform very complex
optimizations that no D compiler today performs. - Being map so easy
to write, to use and to understand, the programmer is able to write
far more complex things. If writing a map requires a tens lines of
complex D code, normal programmers usually don't want to write things
much more complex (type-wise too) than a map.


I'm not sure how that assumption works. Implementing a regex engine is 
quite an endeavor, but that doesn't stop people from using it casually, 
and for higher-level things.


On the Haskell compiler being "... able to perform very complex 
optimizations that no D compiler today performs" I call bullshit. The 
two languages have very different approaches to computation and choose 
right off the bat very different corners of the PL design space. 
Consequently, the challenges met by the two languages are very different 
and the approaches to overcome those challenges are also very different.


Haskell starts with a computational model far removed from the reality 
of the computing fabric it works on. Therefore, it gains some in certain 
areas, but it loses some when it comes to efficiency. Naturally, it 
needs more sophisticated optimizations to overcome that handicap. That 
doesn't mean much in comparing Haskell to D or the quality of a Haskell 
compiler with that of a D compiler.



Python lazy iterators syntax wins over both languages:


collection = xrange(20) [2 * x for x in collection if x<  5]  #
eager

[0, 2, 4, 6, 8]

newcol = (2 * x for x in collection if x<  5)  # lazy
list(newcol)

[0, 2, 4, 6, 8]


I guess I must act impressed.


We should probably add a specialized lambda syntax.


Do you mean something like C# lambdas?


Per Walter's enumeration of syntax in various languages.


I wonder what Scala/Haskell idioms we should borrow for D.


Haskell has several nice ideas, but I think it's not easy to copy
them without changing D a lot. Still, being open toward this idea is
an improvement for D designers :-)


Feel free to spare the patronizing part, it won't be missed.


You want Haskell capability with D performance. You can't have
that.


We live in a world where JavaScript is sometimes only 3-4 times
slower than D code, and where LuaJIT compiles dynamically typed Lua
floating-point-heavy programs and runs them in a total amount of time
lower than just running a binary produced by DMD. So be careful when
you say something is impossible :-)

In the works there is a dialect of Haskell meant for faster
programs: http://www.haskell.org/haskellwiki/DDC


That wasn't my point.


D's map is superior to Haskell's. There is no contest.


Some aspects of D map are superior, and some aspects of Haskell map
are superior to D ones.



(In addition, Hakell's map forces ONE higher-order function
representation, whereas D works with a function alias, function,
or delegate.)


I think this is an advantage of Haskell. I think Haskell doesn't need
those things, it's more uniform.


It's also slower. Per the other half of your other posts, efficiency is 
a huge concern to you.



D also allows things that are essentially impossible in Haskell,
such as quicksort.


The point of this discussion is to look for ways to improve D.
bashing Haskell is off topic and bad.


Nobody's bashing Haskell. But we can't work from the assumption that 
everything in Haskell is non-critically good and has no downsides.



Andrei

Re: C compatibility module for phobos.

[Jonathan M Davis]

On Wednesday, September 21, 2011 11:59 Gor F. Gyolchanyan wrote:
> Thanks! I never new that module existed! It's not mentioned in dpl.org.

Very little of druntime has any documentation - particularly the stuff which 
is just C bindings. We should probably go through there and put empty ddoc 
comments on them so that they can actually be put in the online docs. The 
actual documentation of what they do can be left to the normal C 
documentation, since they're C bindings, but just having empty ddoc comments 
makes it possible to list in the documentation what we have bindings for.

- Jonathan M Davis

Re: Anonymous function syntax

[Adam Ruppe]

deadalnix wrote:
> This makes Javascript's and D's closures the most readable for
> somebody having this background.

Indeed! I find most the proposed lambdas to look like random noise.

D has it good just how it is.

Re: Anonymous function syntax

[deadalnix]

Le 22/09/2011 00:29, bearophile a écrit :

Walter Bright:


D
  (a,b) { return a + b; }


In D to define a true lambda you need types too:
auto f = (int a,int b){ return a + b; };

For D I think I'd like a syntax like:
{ int a, int b =>  a + b }
That in some cases becomes just:
{ a,b =>  a + b }



That would be less readable for somebody coming from a C styled 
language. Curly braces for body and parenthesis for arguments is 
something very familiar.


This makes Javascript's and D's closures the most readable for somebody 
having this background.

Re: The Strange Loop conference

[Peter Alexander]

On 21/09/11 10:11 PM, Andrei Alexandrescu wrote:

On 9/21/11 3:34 PM, Peter Alexander wrote:

The problem it's simply intractable to do lazy computation in D while
maintaining the 'correct' static typing.

For example, in Haskell, map (correctly) has the signature:

map :: (a -> b) -> [a] -> [b]

but in D, std.map has the signature (expressed in some Haskell/D
pseudocode)

map :: (a -> b) -> [a] -> Map!((a -> b), [a])


I think it really is

map :: (a -> b) -> Range1!a -> Map!((a -> b), Range1!a)

i.e. the type of the input range is not fixed to be a built-in list.
That makes D's map more general than Haskell's, but also more difficult
to implement. For example, Haskell's implementation does not need to
worry about O(1) access to the nth element of the result.


True, I oversimplified it.



To get the same kind of signature as Haskell, you'd need to use eager
computation in D, but that's horrendously inefficient in most cases.
Alternatively, you can use interfaces, but then you lose type
information in a lot of situations.

The problem with the D situation is that if I have a function:

void foo(int[])

then it can't be called with:

foo(map!"2*a"([1, 2, 3]));

I'm forced to either:
(a) use eager computation by wrapping it in array(...)
(b) change foo to be a template


This is exactly as it should be. For whatever reason, foo wants an
array. For a good reason, map returns a lazy sequence that depends upon
the type of its input. You necessarily need to force computation into an
array because foo needs an array and because D arrays are eager.

This is tantamount to saying that D is not as good as Haskell at lazy
computation. Fine - lazy computation is Haskell's turf.


Well yes, but that's the whole problem: std.algorithm and std.range 
attempt to act like lazy, functional programming is easy and expressive 
in D, but it's not, except in small self-contained examples.




What if foo is a virtual member function? Those can't be templates.


Then it would need to take a dynamic Range as parameter, parameterized
with the element type.


What if foo recursively maps to itself? e.g.

auto foo(Range)(Range r)
{
if (r.length == 1)
return r.front;
r.popFront();
return map!"2*a"(r);
}


Hm, this is not recursive (and should work).


Apologies, the last line should read:

return foo(map!"2*a"(r));



Someone in D.learn tried to write quickSort in a similar way, but it
obviously doesn't work because of the infinite number of template
instantiations. To simulate lazy computation in D, you require a type
transformation, which doesn't work with recursion. You're only choice is
to abstract away to some sort of IRange!T interface to remove the type
divergence, but then you lose performance, and in some cases, type
information.


But Haskell has lost the performance argument right off the bat.


Maybe.

As I mentioned later on, Haskell can do deforestation optimisations 
(among many other things) that D cannot do due to Haskell's overall 
design (absolute purity).


I'm curious if you have benchmarks to back it up (I don't, but I'm not 
making the claim). In D it's easy to predict performance because there's 
a (relatively) simple mapping of D code to machine code. The same isn't 
true of Haskell.




You are mixing tradeoffs here. There are pretty immutable rules of what
can and cannot be done, many of which are consequences of a handful of
simple facts. You want Haskell capability with D performance. You can't
have that.


Well, as much as I would like that, I'm not arguing for it.

My post was in reply to Timothy saying:

"If I write functional style code in D I unfortunately usually get 
feedback that it is 'extremely hard to read'."


and

"std.algorithm/std.range are also considerably (and as I understand, 
deliberately) underpowered for FP when compared to eg Haskell's standard 
set of libraries"


I understand the tradeoffs D makes, I'm just agreeing and elaborating on 
what Tim said: Phobos' functional offering is underpowered and much more 
difficult to understand compared to Haskell's. As you said, Haskell is 
more capable than D in this area.




Of course, if every function that accepts a range becomes a template
then you have the practical problem of managing the number of template
instantiations. Code bloat is still a real problem with heavy template
usage.

Finally, map in Haskell just makes sense. You have a list of a's, a
function of 'a to b' and you get a list of b's out the other end. It's
simple, it's exactly what you want, and it just works. You can't say the
same in D.


D's map is superior to Haskell's. There is no contest.


It's only superior if you measure superiority on two very specific 
properties:


- Applicability to different data structures
- Performance in simple cases

There are other important properties of Haskell's map that I'm sure 
Haskellite's would use to argue that theirs is superior:


- Simplicity (a couple of lines of code to define with only basic 
language features)


- Gr

Re: D's confusing strings (was Re: D on hackernews)

[Jonathan M Davis]

On Wednesday, September 21, 2011 14:08 Christophe wrote:
> Jonathan M Davis , dans le message (digitalmars.D:144944), a écrit :
> >> I never said there was a problem with drop.
> > 
> > Yes you did. You said:
> > 
> > "mini-quiz: what should std.range.drop(some_string, 1) do ?
> > hint: what it actually does is not what the documentation of phobos
> 
> ^^^
> 
> > suggests*..."
> 
> not documentation of drop.

You weren't specific enough to make it clear what you meant. It looked like
you were complaining about drop's documentation.

> > If you have a better solution, please share it, but the fact that we want
> > both efficiency and correctness binds us pretty thoroughly here.
> 
> - char[], etc. being real arrays.

Which is actually arguably a _bad_ thing, since it doesn't generally make 
sense to operate on individual chars. What you really want 99.999% of 
the time is code points not code units.

> - strings being lazy ranges of dchar, providing access to underlying
> char[].
> 
> Correctness of the langage is better, since we don't have a T[] having a
> front method that returns something else than T, or a type that accepts
> opSlice but is not sliceable, etc.
> 
> Runtime correctness and efficiency are the same as the current ones,
> since the whole phobos already considers strings as lazy range of dchar.
> It is even better, since the user cannot change an arbitrary code point
> in a string without explicitely asking for the undelying char[].
> Optimizations can come the same way as they currently can, since the
> underlying char is accessible.
> 
> I can deal with strings the way they are, since they are an heritage.
> They are not perfect, and will never be unless computers become fat
> enough to treat dchar[] just as efficiently as char[]. I am also aware
> that phobos cannot be optimized for every cases in the first place, and
> I can change my mind.

So, essentially you're arguing for a wrapper around arrays of code units. That 
does add some benefits (such as making foreach default to dchar), but 
ultimately doesn't add that much additional benefit (it also makes dealing 
with array literals much more interesting). If we were to start over again, 
that may very well be the way that we'd go, but the added benefits just don't 
outweigh the immense amount of code breakage which would result. Maybe the 
situation will change with D3, but at this point, I think that we've done a 
fairly good job of making it possible to treat strings as ranges.

- Jonathan M Davis

Re: Anonymous function syntax

[bearophile]

Walter Bright:

> D
>  (a,b) { return a + b; }

In D to define a true lambda you need types too:
auto f = (int a,int b){ return a + b; };

For D I think I'd like a syntax like:
{ int a, int b => a + b }
That in some cases becomes just:
{ a,b => a + b }


> Haskell
>  \a b -> a + b

In Haskell you often don't use lambdas. You curry functions, or your use 
already written little higher order functions/operators to build something, or 
sometimes you use list comprehensions:

http://www.haskell.org/haskellwiki/List_comprehension
take 10 [ (i,j) | i <- [1..], let k = i*i, j <- [1..k]]

In Python too you often use list comprehensions instead of lambdas + filter + 
map.

Bye,
bearophile

Re: The Strange Loop conference

[bearophile]

Peter Alexander:

> auto newrange = filter!"a<5"(map!"2*a"(range));
> 
> At least I think that works??

It works:

import std.stdio, std.range, std.algorithm;
void main() {
auto r = iota(20);
auto n = filter!q{ a < 5 }(map!q{ 2 * a }(r));
writeln(n);
}



> The problem it's simply intractable to do lazy computation in D while
> maintaining the 'correct' static typing.

Both Perl6 and Scala have a "lazy stream" that you use like Haskell lazy lists. 
It is possible to implement something similar to D, recently someone has shown 
some code.


> The problem with the D situation is that if I have a function:
> 
> void foo(int[])
>
> then it can't be called with:
> 
> foo(map!"2*a"([1, 2, 3]));
> 
> I'm forced to either:
> (a) use eager computation by wrapping it in array(...)
> (b) change foo to be a template

This is why I have asked for functions like amap/afilter in Phobos, because in 
many situations in D you need an array instead of a lazy range.


> Of course, if every function that accepts a range becomes a template
> then you have the practical problem of managing the number of template
> instantiations. Code bloat is still a real problem with heavy template
> usage.

Haskell has used typeclasses to avoid this :-)


> Finally, map in Haskell just makes sense. You have a list of a's, a
> function of 'a to b' and you get a list of b's out the other end. It's
> simple, it's exactly what you want, and it just works. You can't say the
> same in D.

I agree. That has two good consequences:
- It makes sense for the Haskell compiler too, so it is able to perform very 
complex optimizations that no D compiler today performs.
- Being map so easy to write, to use and to understand, the programmer is able 
to write far more complex things. If writing a map requires a tens lines of 
complex D code, normal programmers usually don't want to write things much more 
complex (type-wise too) than a map.


> * I say simple cases because Haskell compiler can do deforestation
> optimisations, which are essentially intractable in D due to its
> imperative roots.

I think future D compilers will find some ways to further optimize D code that 
uses purity/immutability a lot.

---

Andrei Alexandrescu:

>> Where D still loses when compared to Scala is functional code syntax:
>>
>> val newcol = collection filter {x=>x<5} map {x=>2*x}
>
> Yoda this wrote.
>
>> or maybe
>>
>> val newcol = for(x<-collection if(x<5)) yield 2*x
>
> Too baroque.
>
>> vs
>>
>> auto newrange = filter!((x){return x<5;})(map!((x){return 2*x;})(range));
>
> auto newrange = filter!"a<5"(map!"2*a"(range));

Python lazy iterators syntax wins over both languages:

>>> collection = xrange(20)
>>> [2 * x for x in collection if x < 5]  # eager
[0, 2, 4, 6, 8]
>>> newcol = (2 * x for x in collection if x < 5)  # lazy
>>> list(newcol)
[0, 2, 4, 6, 8]


> We should probably add a specialized lambda syntax.

Do you mean something like C# lambdas?


> I wonder what Scala/Haskell idioms we should borrow for D.

Haskell has several nice ideas, but I think it's not easy to copy them without 
changing D a lot.
Still, being open toward this idea is an improvement for D designers :-)



Andrei Alexandrescu:

> You want Haskell capability with D performance. You can't have that.

We live in a world where JavaScript is sometimes only 3-4 times slower than D 
code, and where LuaJIT compiles dynamically typed Lua floating-point-heavy 
programs and runs them in a total amount of time lower than just running a 
binary produced by DMD. So be careful when you say something is impossible :-) 

In the works there is a dialect of Haskell meant for faster programs:
http://www.haskell.org/haskellwiki/DDC


> D's map is superior to Haskell's. There is no contest.

Some aspects of D map are superior, and some aspects of Haskell map are 
superior to D ones.


> (In addition, Hakell's map forces ONE higher-order function
> representation, whereas D works with a function alias, function, or
> delegate.)

I think this is an advantage of Haskell. I think Haskell doesn't need those 
things, it's more uniform.


> D also allows things that are essentially impossible in Haskell, such as 
> quicksort.

The point of this discussion is to look for ways to improve D. bashing Haskell 
is off topic and bad.

---

Timon Gehr:

> Pattern matching, if it can be incorporated in a good way.

There are ideas to improve switch a bit:
http://d.puremagic.com/issues/show_bug.cgi?id=596


> Generators?

This is an idea:
http://d.puremagic.com/issues/show_bug.cgi?id=5660


> The range concept is very important in D code, some syntactic sugar like
> this would help a lot.

Right.

Bye,
bearophile

Anonymous function syntax

[Walter Bright]

I've collected a few from various languages for comparison:

D
(a,b) { return a + b; }

Ruby
->(a,b) { a + b }

C++0x
[](int a, int b) { return a + b; }

C#
(a,b) => a + b

Scala
(a:Int, b:Int) => a + b

Erlang
fun(a, b) -> a + b end.

Haskell
\a b -> a + b

Javascript
function(a,b) { return a + b; }

Clojure
# (+ % %2)

Lua
function(a,b) return a + b end

Python
lambda a,b: a + b

Re: Paradox about D's popularity.

[Adam Ruppe]

SWIG kinda scares me... doesn't it generate wrappers instead of
direct calls into the C++? That could easily double the size
of the library.

There's a bugzilla entry with a thing to allow calling into more
of C++'s functions with extern(C++). I'd like to see that pulled
into the tree if it passes Walter's eye.

http://d.puremagic.com/issues/show_bug.cgi?id=4620

Re: The Strange Loop conference

[Timon Gehr]

On 09/21/2011 11:11 PM, Andrei Alexandrescu wrote:

On 9/21/11 3:34 PM, Peter Alexander wrote:

What if foo is a virtual member function? Those can't be templates.


Then it would need to take a dynamic Range as parameter, parameterized
with the element type.



Would it be a good idea to allow this?

to!Interface(structInstance);

This would work if Struct implicitly fulfills the interface and return a 
class instance that is constructed on the fly and implements the 
interface by forwarding to the struct instance.


foo(to!IInputRange(map!(...)(...)));

Re: Paradox about D's popularity.

[maarten van damme]

about interfacing to d:
There was some kind of tool out there that is never mentioned on one of the
d websites called swig. If you can make it extremely easy and get the bugs
out of the way (maybe even write a decent tutorial on it which I really
need) linking to c++ would be a breeze.

as for promoting the d programming language I think you should start with
wikipedia. I stranded here because I was sick of java's tunnel-visioned
object-oriented too verbose syntax. c++ was just too damn ugly to look at so
I played a bit with scale/python/c#,... In my search to other languages I
looked up all languages with a similar style to java and saw a page about D
and thought by myself "yet another letter of the alphabet". I kept reading
though and saw the code examples. It looked beautiful.
But then I read a bit further and saw all it's shortcommings. still
interested I went to the digitalmars homepage and got lost somewhere over
there with D1 and D2. After that I went to dsource and saw dead forums and
outdated projects so I gave up on D.
A bit later though I read something about D which was prety recent with a
lot of great responses on so I went back to the digitalmars homepage and
tried the newsgroups. Luckely they were very vivid.

Next big step: learning the language. A lot was similar to java but I wanted
to learn about those features getting promoted in debates against c++. I
found some tutorials on D but they were not sufficient to learn from.
Luckely alexandrescu's book was so complete, well writen and easy to follow.

I think to increase D's popularity one could
- increase ease of linking to c(++) (maybe through swig?)
- rewrite the wikipedia page (seriously)
- revamp dsource. It would be great to see news from the blog "the one with
d" apearing on the dsource homepage. A lot of dead projects should be
archived and one should mention in the forums that a better place to try is
the d newsgroup.
- write some tutorials (always helps)
- get D on some benchmark charts

Great to see someone so motivated joining, good luck :)

Re: The Strange Loop conference

[Timon Gehr]

On 09/21/2011 10:20 PM, Andrei Alexandrescu wrote:

On 9/21/11 2:29 PM, Timon Gehr wrote:

On 09/21/2011 06:55 PM, Andrei Alexandrescu wrote:

I'm back from the Strange Loop conference. It's been an interesting
experience. The audience was very diverse, with interest in everything
functional (you'd only need to say "Haskell" or "monad" to get positive
aahs), Web/cloud/tablet stuff, concurrent and distributed systems.
Mentioning C++ non-mockingly was all but a faux pas; languages like
Scala, Haskell, Clojure, and Erlang got attention. The quality of talks
has been very variable, and unfortunately the
over-confident-but-clueless-speaker stereotype was well represented.

I gave a talk there
(https://thestrangeloop.com/sessions/generic-programming-galore-using-d)
which has enjoyed moderate audience and success. I uploaded the slides
at http://erdani.com/d/generic-programming-galore.pdf and the video may
be available soon.


I am looking forward to it!



There was a very strong interest in D's CTFE abilities, which we should
consider a strategic direction going forward.


One milestone would be to make DMD GC enabled. CTFE string manipulation
sucks up too much memory.


Also finalizing D's
concurrency language and library infrastructure is essential. These two
features are key differentiators. Also, capitalizing on D's functional
features (which are e.g. better than Scala's but less known) would add
good value.



Where D still loses when compared to Scala is functional code syntax:

val newcol = collection filter {x=>x<5} map {x=>2*x}


Yoda this wrote.


Actually it is the order in which it will (conceptually at least) be 
executed =). D can do similar things on arrays with UFCS.





or maybe

val newcol = for(x<-collection if(x<5)) yield 2*x


Too baroque.


vs

auto newrange = filter!((x){return x<5;})(map!((x){return 2*x;})(range));


auto newrange = filter!"a<5"(map!"2*a"(range));

At first some people get the heebiejeebies when seeing string-based
lambda and the implicit naming convention for unary and binary
functions.


Yes, I have seen it happen multiple times. There are even people who 
consider strings-as-code an evil concept entirely :o). How are CTFE and 
string mixins best introduced to people who think they might be too lazy 
to bother about learning more about the language?



More importantly, there's the disadvantage you can't access
local functions inside a string lambda.


I often want to do that. We could replace the 5 and 2 constants by stack 
variables, and then the point would be made.



We should probably add a
specialized lambda syntax.


It would probably be a simple addition as it is restricted mostly to the 
parser.


Like this? Or is there a better lambda syntax around?

int u,v;
auto newrange=map!(x=>u*x)(filter!(x=>vvu*x);





I believe that is part of the reason why it is less known. If I write
functional style code in D I unfortunately usually get feedback that it
is "extremely hard to read". Furthermore, Scala has built-in tuples, and
eg delimited continuations, which enable some more functional
programming idioms. std.algorithm/std.range are also considerably (and
as I understand, deliberately) underpowered for FP when compared to eg
Haskell's standard set of libraries, and writing a good range from
scratch is usually a serious undertaking.


I wonder what Scala/Haskell idioms we should borrow for D.


In my opinion these are worth looking into:

Haskell: This might not happen, but having a tiny little function with a 
literate name for most common tasks is very convenient. I think other 
Haskell idioms not already in D are hard to translate because the type 
system and execution model of the two languages are so different. I have 
managed to use D for haskell-lookalike toy examples nonetheless. (it 
leads to extremely obfuscated code because of many nested lambdas and a 
bug in the lazy storage class that needs to be worked around)


Both: (Concise expression-based lambdas.) Pattern matching, if it can be 
incorporated in a good way. (dynamic) lazy evaluation. Scala has lazy 
val. It would play very nicely with Ds purity, but maybe suboptimally 
with immutable (for immutable structures, the lazy fields would have to 
be computed eagerly)


Generators? (those are implicit in Haskell) Something like this example 
would automatically create a compile-time lazy range to compute a power 
set efficiently.


auto powerset(T)(T[] x) {
foreach(i;0..1

Re: Paradox about D's popularity.

[Dmitry Olshansky]

On 22.09.2011 1:14, Gor F. Gyolchanyan wrote:

I had an idea of a D library for including C headers for a while now.
All i need is to make a compile-time C parser for that. This thing would 
literally
remove any need for binding.


Translating header file is a one-time job, as in
sh-$: translate fancy.h fancy.di

Why would you need to do it at compile time, except because it's fancy 
:), I don't quite get.


And, as much as I'm sorry to bring bad news, you'd have to make a C 
preprocessor as well (or even in the first place). Then you'd have to 
struggle through vendor extensions but that's doable.




--
Dmitry Olshansky

Re: The Strange Loop conference

[Andrei Alexandrescu]

On 9/21/11 3:34 PM, Peter Alexander wrote:

The problem it's simply intractable to do lazy computation in D while
maintaining the 'correct' static typing.

For example, in Haskell, map (correctly) has the signature:

map :: (a -> b) -> [a] -> [b]

but in D, std.map has the signature (expressed in some Haskell/D
pseudocode)

map :: (a -> b) -> [a] -> Map!((a -> b), [a])


I think it really is

map :: (a -> b) -> Range1!a -> Map!((a -> b), Range1!a)

i.e. the type of the input range is not fixed to be a built-in list. 
That makes D's map more general than Haskell's, but also more difficult 
to implement. For example, Haskell's implementation does not need to 
worry about O(1) access to the nth element of the result.



To get the same kind of signature as Haskell, you'd need to use eager
computation in D, but that's horrendously inefficient in most cases.
Alternatively, you can use interfaces, but then you lose type
information in a lot of situations.

The problem with the D situation is that if I have a function:

void foo(int[])

then it can't be called with:

foo(map!"2*a"([1, 2, 3]));

I'm forced to either:
(a) use eager computation by wrapping it in array(...)
(b) change foo to be a template


This is exactly as it should be. For whatever reason, foo wants an 
array. For a good reason, map returns a lazy sequence that depends upon 
the type of its input. You necessarily need to force computation into an 
array because foo needs an array and because D arrays are eager.


This is tantamount to saying that D is not as good as Haskell at lazy 
computation. Fine - lazy computation is Haskell's turf.



What if foo is a virtual member function? Those can't be templates.


Then it would need to take a dynamic Range as parameter, parameterized 
with the element type.



What if foo recursively maps to itself? e.g.

auto foo(Range)(Range r)
{
if (r.length == 1)
return r.front;
r.popFront();
return map!"2*a"(r);
}


Hm, this is not recursive (and should work).


Someone in D.learn tried to write quickSort in a similar way, but it
obviously doesn't work because of the infinite number of template
instantiations. To simulate lazy computation in D, you require a type
transformation, which doesn't work with recursion. You're only choice is
to abstract away to some sort of IRange!T interface to remove the type
divergence, but then you lose performance, and in some cases, type
information.


But Haskell has lost the performance argument right off the bat.

You are mixing tradeoffs here. There are pretty immutable rules of what 
can and cannot be done, many of which are consequences of a handful of 
simple facts. You want Haskell capability with D performance. You can't 
have that.



Of course, if every function that accepts a range becomes a template
then you have the practical problem of managing the number of template
instantiations. Code bloat is still a real problem with heavy template
usage.

Finally, map in Haskell just makes sense. You have a list of a's, a
function of 'a to b' and you get a list of b's out the other end. It's
simple, it's exactly what you want, and it just works. You can't say the
same in D.


D's map is superior to Haskell's. There is no contest.

Again, Haskell's map forces only ONE range abstractions to fit 
everybody. D's map allows anyone to choose their own map abstraction, 
and is clever enough to define another map abstraction based on it that 
offers maximum capability and maximum efficiency.


(In addition, Hakell's map forces ONE higher-order function 
representation, whereas D works with a function alias, function, or 
delegate.)



Of course, what D's lazy ranges do give you is performance in the simple
cases*. There's no indirect function calls, which means things can be
inlined, and you save yourself a few potential cache misses. We just
have to accept that this performance is at the expense of simplicity and
expressability.


You could have indirect calls in D.


* I say simple cases because Haskell compiler can do deforestation
optimisations, which are essentially intractable in D due to its
imperative roots.


D also allows things that are essentially impossible in Haskell, such as 
quicksort.



Andrei

Re: Paradox about D's popularity.

[Gor F. Gyolchanyan]

I had an idea of a D library for including C headers for a while now.
All i need is to make a compile-time C parser for that. This thing would 
literally
remove any need for binding. Doing the same for C++ would be much much harder, 
though.

Re: Paradox about D's popularity.

[Jesse Phillips]

Gor F. Gyolchanyan Wrote:

> I'll look up any kind of programming language related sites and try to put D 
> put
> there.

One problem we have is that there are many that have heard of D, but they 
either don't hear it enough to consider it any good or know of some problem 
that may have already been fixed or will be fixed and can't let it go.

> Another big downside, that i noticed in development of D and DMD is
> unpredictability. I think we should make schedules for regular releases of 
> batches
> of bug-fixes and feature enhancements of DMD, so that people will be able to 
> use
> yet-unimplemented features of they're certainly going to be implemented in the
> next release.

For the most part someone would need to take this role. As a body of volunteers 
people do what itches them the most. If someone maintained a list of bugs that 
should be fixed in the next X number of releases it would server as a good 
reference even if they are not all tackled. And it must take input from the 
volunteers on which they will be working on.

There is a general consensus on what type of reports get priority over others. 
DMD does get fairly regular releases and can't always stick to a tight 
schedule. Once a month has been the norm while 2-3 months may pass.

http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#Roadmap
 
> Also in the light of recent investigation, i think it would be very wise to 
> turn
> our attention to enhance D's compatibility with C++, since this is one of the
> biggest problems, that companies will face if they decide to switch to D. If D
> gains a good enough compatibility with C++ (i know, it's a really difficult 
> job),

To my understanding D does have good support for C++ now. The limitations come 
from multiple inheritance, like you said, and templates.

Multiple inheritance of C++ won't be supported as D doesn't have any mapping 
for it.

Templates are a problem because they must be compiled, and DMD will not include 
a C++ parser just to have access to templates.

> then the cost of switching to D will dramatically decrease, because less and 
> less
> C++ code will need to be rewritten. For those cases when direct access to C++ 
> is
> impossible (probably, with multiple inheritance involved), we could make D
> libraries, that would interpret C++ headers at compile time and generate 
> wrappers
> around it (and such).

Wouldn't this basically be a C++ to C interfacing tool? Such a tool sounds kind 
of interesting, does one exist? Why doesn't one exist? Why do existing ones not 
get used?

> It'll take a lot of effort, but it's possible and given the current situation 
> of
> commercial non-usability of D it would be a good idea.

Welcome and good luck promoting D. Please select something you wish to work on 
and I hope you'll find the support you need. Remember we are a small community 
and all have something we wish D was better at. And as Bearophile points out, 
we should be looking to advertise with the right information at the right time.

Re: D's confusing strings (was Re: D on hackernews)

[Christophe]

Jonathan M Davis , dans le message (digitalmars.D:144944), a écrit :
>> I never said there was a problem with drop.
> 
> Yes you did. You said:
> 
> "mini-quiz: what should std.range.drop(some_string, 1) do ?
> hint: what it actually does is not what the documentation of phobos 
  ^^^
> suggests*..."
not documentation of drop.

> If you have a better solution, please share it, but the fact that we want 
> both 
> efficiency and correctness binds us pretty thoroughly here.

- char[], etc. being real arrays.
- strings being lazy ranges of dchar, providing access to underlying 
char[].

Correctness of the langage is better, since we don't have a T[] having a 
front method that returns something else than T, or a type that accepts 
opSlice but is not sliceable, etc.

Runtime correctness and efficiency are the same as the current ones, 
since the whole phobos already considers strings as lazy range of dchar. 
It is even better, since the user cannot change an arbitrary code point 
in a string without explicitely asking for the undelying char[]. 
Optimizations can come the same way as they currently can, since the 
underlying char is accessible.

I can deal with strings the way they are, since they are an heritage. 
They are not perfect, and will never be unless computers become fat 
enough to treat dchar[] just as efficiently as char[]. I am also aware 
that phobos cannot be optimized for every cases in the first place, and 
I can change my mind.

-- 
Christophe

Re: Paradox about D's popularity.

[Gor F. Gyolchanyan]

You're right. I gotta apologize for my over-reaction to D's problems. It's just,
that i want it to thrive. Maybe i care too much and i make too bit a deal out of
this. :-)

Re: Paradox about D's popularity.

[bearophile]

Andrei Alexandrescu:

> Different people work on different things. Firing shoemakers won't 
> produce more bakers.

Right. The life of Open Source projects is not linear :-)

Regarding the DMD pull requests in GitHut that are currently open (and the 
future ones that people will add), in my ignorant and humble opinion I think it 
will be better to manage that list as a "priority queue" instead of a "almost 
Last-In-First-Out" stack-like as it seems now.

Bye,
bearophile

Re: D's confusing strings (was Re: D on hackernews)

[Andrei Alexandrescu]

On 9/21/11 3:26 PM, Christophe Travert wrote:

Andrei Alexandrescu , dans le message (digitalmars.D:144936), a écrit :

On 9/21/11 1:20 PM, Christophe Travert wrote:

Dealing with utfencoded strings is less efficient, but there is a number
of algorithms that can be optimized for utfencoded strings, like copying
or finding an ascii char in a string. Unfortunately, there is no
practical way to do this with the current range API.


I'd love to hear more about that. The standard library does optimize
certain algorithms for UTF strings.



Well, in that other thread called "Re: toUTFz and WinAPI
GetTextExtentPoint32W/" in D.learn (what is the proper way to refer to
a message here ?), I showed how to improve walkLength for strings and
utf.stride.


Interesting, thanks.


About finding a character in a string, rather than relying
on string.popFront, which makes the loop un-unrollable,
we could search code unit per code unit directly. This is obviously
better for ascii char, and I'll be looking for a nice idea for other
code points (besides using find(Range, Range)).

I didn't review phobos with that idea in mind, and didn't do any
benchmark exept the one for walkLength, but using string.popFront is a
bad idea in term of performance, so work-arrounds are often better, and
they are not that hard to find. I may do that when I have more time to
give to D.


That sounds great. Looking forward to your pull requests!

Andrei

Re: The Strange Loop conference

[Sean Kelly]

On Sep 21, 2011, at 12:59 PM, Andrei Alexandrescu wrote:

> On 9/21/11 12:59 PM, bearophile wrote:
>> Andrei Alexandrescu:
>> 
>>> which has enjoyed moderate audience and success. I uploaded the
>>> slides at http://erdani.com/d/generic-programming-galore.pdf and
>>> the video may be available soon.
>> 
>> In future talks I suggest to show some downsides too, like explaining
>> how much memory uses the D RE engine, how hard are to write, read,
>> modify and debug text-based mixins like the bitfields, etc.
> 
> I did mention the downsides in the talk: memory consumption during CTFE and 
> the compiler's inability to explain why a template didn't match.

If DMD cleaned up after itself, the memory consumption issue would be far less 
significant though.  Perhaps DMD could be fixed up to the point where GC could 
be enabled?  I recall the code being there, but that there were issues with 
turning it on.

Re: The Strange Loop conference

[Peter Alexander]

On 21/09/11 8:29 PM, Timon Gehr wrote:

Where D still loses when compared to Scala is functional code syntax:

val newcol = collection filter {x=>x<5} map {x=>2*x}

or maybe

val newcol = for(x<-collection if(x<5)) yield 2*x

vs

auto newrange = filter!((x){return x<5;})(map!((x){return 2*x;})(range));


Of course, you could write:

auto newrange = filter!"a<5"(map!"2*a"(range));

At least I think that works??



I believe that is part of the reason why it is less known. If I write
functional style code in D I unfortunately usually get feedback that it
is "extremely hard to read". Furthermore, Scala has built-in tuples, and
eg delimited continuations, which enable some more functional
programming idioms. std.algorithm/std.range are also considerably (and
as I understand, deliberately) underpowered for FP when compared to eg
Haskell's standard set of libraries, and writing a good range from
scratch is usually a serious undertaking.


The problem it's simply intractable to do lazy computation in D while 
maintaining the 'correct' static typing.


For example, in Haskell, map (correctly) has the signature:

map :: (a -> b) -> [a] -> [b]

but in D, std.map has the signature (expressed in some Haskell/D pseudocode)

map :: (a -> b) -> [a] -> Map!((a -> b), [a])

To get the same kind of signature as Haskell, you'd need to use eager 
computation in D, but that's horrendously inefficient in most cases. 
Alternatively, you can use interfaces, but then you lose type 
information in a lot of situations.


The problem with the D situation is that if I have a function:

void foo(int[])

then it can't be called with:

foo(map!"2*a"([1, 2, 3]));

I'm forced to either:
(a) use eager computation by wrapping it in array(...)
(b) change foo to be a template

What if foo is a virtual member function? Those can't be templates.

What if foo recursively maps to itself? e.g.

auto foo(Range)(Range r)
{
if (r.length == 1)
return r.front;
r.popFront();
return map!"2*a"(r);
}

Someone in D.learn tried to write quickSort in a similar way, but it 
obviously doesn't work because of the infinite number of template 
instantiations. To simulate lazy computation in D, you require a type 
transformation, which doesn't work with recursion. You're only choice is 
to abstract away to some sort of IRange!T interface to remove the type 
divergence, but then you lose performance, and in some cases, type 
information.


Of course, if every function that accepts a range becomes a template 
then you have the practical problem of managing the number of template 
instantiations. Code bloat is still a real problem with heavy template 
usage.


Finally, map in Haskell just makes sense. You have a list of a's, a 
function of 'a to b' and you get a list of b's out the other end. It's 
simple, it's exactly what you want, and it just works. You can't say the 
same in D.


Of course, what D's lazy ranges do give you is performance in the simple 
cases*. There's no indirect function calls, which means things can be 
inlined, and you save yourself a few potential cache misses. We just 
have to accept that this performance is at the expense of simplicity and 
expressability.


* I say simple cases because Haskell compiler can do deforestation 
optimisations, which are essentially intractable in D due to its 
imperative roots.

Re: D's confusing strings (was Re: D on hackernews)

[Christophe Travert]

Andrei Alexandrescu , dans le message (digitalmars.D:144936), a écrit :
> On 9/21/11 1:20 PM, Christophe Travert wrote:
>> Dealing with utfencoded strings is less efficient, but there is a number
>> of algorithms that can be optimized for utfencoded strings, like copying
>> or finding an ascii char in a string. Unfortunately, there is no
>> practical way to do this with the current range API.
> 
> I'd love to hear more about that. The standard library does optimize 
> certain algorithms for UTF strings.


Well, in that other thread called "Re: toUTFz and WinAPI 
GetTextExtentPoint32W/" in D.learn (what is the proper way to refer to 
a message here ?), I showed how to improve walkLength for strings and 
utf.stride.

About finding a character in a string, rather than relying 
on string.popFront, which makes the loop un-unrollable, 
we could search code unit per code unit directly. This is obviously 
better for ascii char, and I'll be looking for a nice idea for other 
code points (besides using find(Range, Range)).

I didn't review phobos with that idea in mind, and didn't do any 
benchmark exept the one for walkLength, but using string.popFront is a 
bad idea in term of performance, so work-arrounds are often better, and 
they are not that hard to find. I may do that when I have more time to 
give to D.

-- 
Christophe

Re: D's confusing strings (was Re: D on hackernews)

[Jonathan M Davis]

On Wednesday, September 21, 2011 19:56:47 Christophe wrote:
> "Jonathan M Davis" , dans le message (digitalmars.D:144922), a écrit :
> > 1. drop says nothing about slicing.
> > 2. popFrontN (which drop calls) says that it slices for ranges that
> > support slicing. Strings do not unless they're arrays of dchar.
> > 
> > Yes, hasSlicing should probably be clearer about narrow strings, but
> > that has nothing to do with drop.
> 
> I never said there was a problem with drop.

Yes you did. You said:

"mini-quiz: what should std.range.drop(some_string, 1) do ?
hint: what it actually does is not what the documentation of phobos 
suggests*..."

> After having read all of you, I have no problems with string being a
> lazy range of dchar. But I have a problem with immutable(char)[] being
> lazy range of dchar (ie not being a array), and I have a problem with
> string being immutable(char)[] (ie providing length opIndex and
> opSlice).

For efficiency, you need to be able to treat strings as arrays of code units 
for 
some algorithms. For correctness, you need to be able to treat them as ranges 
of code points (dchar) in the general case. You need both. The question is how 
to provide that. strings as arrays came first (D1), whereas ranges came later. 
We _need_ to treat strings as ranges of dchar or they're essentially unusable 
in the general case. Operating on code units is almost always _wrong_. So, 
when we added the range functions, we special-cased them for strings so that 
strings are treated as ranges of dchar as they need to be. And in cases where 
you actually need to treat a string as an array of code units for efficiency, 
you special case the function for them, and you still get that. What other way 
would you do it?

There _are_ some edges here - such as foreach defalting to char for string 
when dchar is really what you shoud be iterating with - and there are times 
when you want to use a string with a range-based function and can't, because 
it needs a random-access range or one which is sliceable to do what it does, 
which can be annoying. But what else can you do there? You can't treat the 
string as a range of code units in that case. The result would be completely 
wrong. Imagine if sort worked on a char[]. You'd get an array of sorted code 
units, which would _not_ be code points, and which would be completely 
useless. So, treating a string as a range of code units makes no sense.

We could switch to having a struct of some kind which was a string, make it a 
range of dchar, and have it contain an array of char, wchar, or dchar 
internally. It would have to restrict its operations in exactly the same 
manner that the range functions for strings currently do, so the exact same 
algorithms would or wouldn't work with it. And then you'd need to provide 
access to the underlying array of code units so that algorithms special casing 
strings could operate on the array instead. Ultimately, it's pretty much the 
same thing, except now you have a wrapper struct. How does that buy you 
anything? The _only_ thing that it would buy you AFAIK is that foreach would 
then default to dchar instead of the code unit type. The basic problem still 
exists. You still need to special case strings for efficiency, and you still 
need to treat them as a range of dchar in the general case. It's an inherent 
issue with variable length encodings. You can't just magically make it go 
away.

If you have a better solution, please share it, but the fact that we want both 
efficiency and correctness binds us pretty thoroughly here.

- Jonathan M Davis

Re: The Strange Loop conference

[Andrei Alexandrescu]

On 9/21/11 2:29 PM, Timon Gehr wrote:

On 09/21/2011 06:55 PM, Andrei Alexandrescu wrote:

I'm back from the Strange Loop conference. It's been an interesting
experience. The audience was very diverse, with interest in everything
functional (you'd only need to say "Haskell" or "monad" to get positive
aahs), Web/cloud/tablet stuff, concurrent and distributed systems.
Mentioning C++ non-mockingly was all but a faux pas; languages like
Scala, Haskell, Clojure, and Erlang got attention. The quality of talks
has been very variable, and unfortunately the
over-confident-but-clueless-speaker stereotype was well represented.

I gave a talk there
(https://thestrangeloop.com/sessions/generic-programming-galore-using-d)
which has enjoyed moderate audience and success. I uploaded the slides
at http://erdani.com/d/generic-programming-galore.pdf and the video may
be available soon.


I am looking forward to it!



There was a very strong interest in D's CTFE abilities, which we should
consider a strategic direction going forward.


One milestone would be to make DMD GC enabled. CTFE string manipulation
sucks up too much memory.


Also finalizing D's
concurrency language and library infrastructure is essential. These two
features are key differentiators. Also, capitalizing on D's functional
features (which are e.g. better than Scala's but less known) would add
good value.



Where D still loses when compared to Scala is functional code syntax:

val newcol = collection filter {x=>x<5} map {x=>2*x}


Yoda this wrote.


or maybe

val newcol = for(x<-collection if(x<5)) yield 2*x


Too baroque.


vs

auto newrange = filter!((x){return x<5;})(map!((x){return 2*x;})(range));


auto newrange = filter!"a<5"(map!"2*a"(range));

At first some people get the heebiejeebies when seeing string-based 
lambda and the implicit naming convention for unary and binary 
functions. More importantly, there's the disadvantage you can't access 
local functions inside a string lambda. We should probably add a 
specialized lambda syntax.



I believe that is part of the reason why it is less known. If I write
functional style code in D I unfortunately usually get feedback that it
is "extremely hard to read". Furthermore, Scala has built-in tuples, and
eg delimited continuations, which enable some more functional
programming idioms. std.algorithm/std.range are also considerably (and
as I understand, deliberately) underpowered for FP when compared to eg
Haskell's standard set of libraries, and writing a good range from
scratch is usually a serious undertaking.


I wonder what Scala/Haskell idioms we should borrow for D.


Another big advantage that Scala has is that it supports pattern
matching. It is usually about the first feature functional programmers
care about.

What do you think is the biggest advantage that Ds functional
programming has in comparison to Scala's?


1. True immutability

2. True purity

3. Pass by alias

For a language that has so firmly branded itself as functional, Scala 
has a surprisingly poor handling of immutability and referential 
transparency aka purity. My understanding is that Scala's immutability 
merely consists of final values and a web of conventions. (Please 
correct me if I'm wrong.)



Andrei

Re: Paradox about D's popularity.

[Gor F. Gyolchanyan]

I was thinking more about baking shoes :-)

Seriously, though, we could start off by making a precise plan for future work.
Then we'll be able to gain a better control of overall work on DMD and phobos 
and
the shoemakers would make the required shoes. Unless I'm missing something and a
similar organizational activity is already going on.

Re: Paradox about D's popularity.

[Andrei Alexandrescu]

On 9/21/11 2:23 PM, Gor F. Gyolchanyan wrote:

As much as I'd like D to develop sweet language features like named
function parameters, directing effort to increase compatibility of D
with other languages (most notably, C++) would be a better idea,
because if D gets cheaper and cheaper to use with existing code base,
more and more people will start caring about D and the aforementioned
sweet language features will get implemented more rapidly.

If Walter, Andrei and others agree with my proposal, i suggest to
postpone all enhancement requests for D, except compatibility-related
ones and direct all our attention to it. As well as direct more
attention towards fixing DMD bugs, rather then developing phobos
libraries, because as much as developing phobos is important, having
a stable compiler is much more important.


Different people work on different things. Firing shoemakers won't 
produce more bakers.


Andrei

Re: isInputRange bug?

[Jonas Drewsen]

On 21/09/11 21.52, Timon Gehr wrote:

On 09/21/2011 09:42 PM, Jonas Drewsen wrote:

isInputRange!(immutable(void)[]) => false
isInputRange!(immutable(char)[]) => true

shouldn't both of them return true?

/Jonas


immutable(void)[] is not a range because you cannot get it's front element.


I see. Thank you.

/Jonas

Re: Paradox about D's popularity.

[Jonathan M Davis]

On Wednesday, September 21, 2011 19:23:32 Gor F. Gyolchanyan wrote:
> As much as I'd like D to develop sweet language features like named function
> parameters, directing effort to increase compatibility of D with other
> languages (most notably, C++) would be a better idea, because if D gets
> cheaper and cheaper to use with existing code base, more and more people
> will start caring about D and the aforementioned sweet language features
> will get implemented more rapidly.
> 
> If Walter, Andrei and others agree with my proposal, i suggest to postpone
> all enhancement requests for D, except compatibility-related ones and
> direct all our attention to it. As well as direct more attention towards
> fixing DMD bugs, rather then developing phobos libraries, because as much
> as developing phobos is important, having a stable compiler is much more
> important.

With the release of TDPL, major feature changes to the language slowed down 
considerably. Features have been being added or changed primarily when it was 
deemed necessary to make features useable and them work as their supposed to 
(e.g. the addition of purity/@safe/nothrow inference for templates). Some 
smaller features have been added, but overall, the focus has been on fixing 
bugs in dmd and completing the implementation of existing features. So, 
nothing would really be gained by postponing enhancement requests at this 
point. Pretty much anything major has been put off until D3 already. Maybe some 
backwards-compatible features will be added to D2 later, but that sort of 
thing isn't generally being done right now. Rather, we've been getting a lot 
of bug fixes for dmd (and with the shift to github, the number and speed of bug 
fixes has increased considerably; the number of bug fixes for the last couple 
of 
releases has been huge).

- Jonathan M Davis

Re: Go and generic programming on reddit, also touches on D

[Andrei Alexandrescu]

On 9/21/11 1:49 PM, Don wrote:

On 19.09.2011 18:12, Andrei Alexandrescu wrote:

On 9/19/11 10:46 AM, Robert Jacques wrote:

So, on balance, I'd say the two pointers representation is categorically
worse than the fat pointer representation.


Benchmark. A few of your assumptions don't hold.

Andrei


Note that high-performance libraries that use slices, like GMP and the
many BLAS libraries, use the pointer+length representation, not
pointer+pointer. They've done a lot of benchmarking on a huge range of
architectures, with a large range of compilers.

The underlying reason for this, is that almost all CISC instruction sets
have built-in support for pointer+length. AFAIK nothing has builtin
support for ptr+ptr.

On x86, you have this wonderful [EAX+8*EBX] addressing mode, that can be
used on almost every instruction, so that the calculation [addr +
sz*index] takes ZERO clock cycles when sz is a power of 2.
Generally, when you supply two pointers, the optimizer will try to
convert it into ptr + offset (where offset isn't bytes, it corresponds
to D's length).


To all who replied and tested - color me convinced we should keep the 
current state of affairs. Thanks!


Andrei

Re: D's confusing strings (was Re: D on hackernews)

[Andrei Alexandrescu]

On 9/21/11 1:20 PM, Christophe Travert wrote:

Dealing with utfencoded strings is less efficient, but there is a number
of algorithms that can be optimized for utfencoded strings, like copying
or finding an ascii char in a string. Unfortunately, there is no
practical way to do this with the current range API.


I'd love to hear more about that. The standard library does optimize 
certain algorithms for UTF strings.


Andrei

Re: The Strange Loop conference

[Andrei Alexandrescu]

On 9/21/11 12:59 PM, bearophile wrote:

Andrei Alexandrescu:


which has enjoyed moderate audience and success. I uploaded the
slides at http://erdani.com/d/generic-programming-galore.pdf and
the video may be available soon.


In future talks I suggest to show some downsides too, like explaining
how much memory uses the D RE engine, how hard are to write, read,
modify and debug text-based mixins like the bitfields, etc.


I did mention the downsides in the talk: memory consumption during CTFE 
and the compiler's inability to explain why a template didn't match.


Andrei

Re: D's confusing strings (was Re: D on hackernews)

[Christophe]

"Jonathan M Davis" , dans le message (digitalmars.D:144922), a écrit :
> 1. drop says nothing about slicing.
> 2. popFrontN (which drop calls) says that it slices for ranges that support 
> slicing. Strings do not unless they're arrays of dchar.
> 
> Yes, hasSlicing should probably be clearer about narrow strings, but that has 
> nothing to do with drop.

I never said there was a problem with drop.

> char a = 'ä';
> 
> shouldn't even be legal. It's a compiler bug.

I figured that out.
I wanted to show that a char couldn't hold a code point, but I was too 
fast and confused code points with code units.

>> Dealing with utfencoded strings is less efficient, but there is a number
>> of algorithms that can be optimized for utfencoded strings, like copying
>> or finding an ascii char in a string. Unfortunately, there is no
>> practical way to do this with the current range API.

Maybe there should be a way for the designer of a class to provide an 
overload for some algorithms, like forwarding to myClass.algorithm for 
instance. The problem is that this is an open door for unvoluntary 
hacking.

Oh, I just noticed I'm actually answering to myself. Thinking out loud, 
am I ?

> [...]

After having read all of you, I have no problems with string being a 
lazy range of dchar. But I have a problem with immutable(char)[] being 
lazy range of dchar (ie not being a array), and I have a problem with 
string being immutable(char)[] (ie providing length opIndex and 
opSlice).

Thanks
-- 
Christophe

Re: The Strange Loop conference

[Timon Gehr]

On 09/21/2011 09:44 PM, Andrej Mitrovic wrote:

What is the purpose of this ternary operator on slide 16?
static if (is(typeof(1 ? T[0].init : T[1].init) U))


This does the bulk of the work to get the combined type of T[0] and 
T[1]. It basically just asks the compiler what the combined type should 
be. It works because the result type of the ternary operator is the 
combined type of it's second and third arguments.

Re: Paradox about D's popularity.

[Don]

On 21.09.2011 21:23, Gor F. Gyolchanyan wrote:

As much as I'd like D to develop sweet language features like named function
parameters, directing effort to increase compatibility of D with other languages
(most notably, C++) would be a better idea, because if D gets cheaper and 
cheaper
to use with existing code base, more and more people will start caring about D 
and
the aforementioned sweet language features will get implemented more rapidly.

If Walter, Andrei and others agree with my proposal, i suggest to postpone all
enhancement requests for D, except compatibility-related ones and direct all our
attention to it.


> As well as direct more attention towards fixing DMD bugs, rather

then developing phobos libraries, because as much as developing phobos is
important, having a stable compiler is much more important.


Most of the attention is already going to DMD.
On git, to date:
DMD pull requests: 401
Phobos pull requests:  272
Druntime pull requests: 74

I find this quite surprising. DMD benefited enormously in moving from 
svn to git. Phobos development seems to have scarcely changed.

Re: isInputRange bug?

[Timon Gehr]

On 09/21/2011 09:42 PM, Jonas Drewsen wrote:

isInputRange!(immutable(void)[]) => false
isInputRange!(immutable(char)[]) => true

shouldn't both of them return true?

/Jonas


immutable(void)[] is not a range because you cannot get it's front element.

isInputRange bug?

[Jonas Drewsen]

isInputRange!(immutable(void)[]) => false
isInputRange!(immutable(char)[]) => true

shouldn't both of them return true?

/Jonas

Re: C compatibility module for phobos.

[Gor F. Gyolchanyan]

For that, there are a number of GC-related bugs to be fixed. If GC gets fully
stable and predictable, C-managed memory could be integrated in concert with GC
(like, making the GC call C-AI's custom free function on collection cycle).

Re: The Strange Loop conference

[Andrej Mitrovic]

What is the purpose of this ternary operator on slide 16?
static if (is(typeof(1 ? T[0].init : T[1].init) U))

Re: C compatibility module for phobos.

[Andrej Mitrovic]

On 9/21/11, Gor Gyolchanyan  wrote:
> If we get a good enough C compatibility module, we'll be able to rapidly
> bind all major and frequently-used libraries and include them in phobos.

Type compatibility might be just the tip of the iceberg for wrapping a
C library. For example you might also have to worry about memory
management, and then there are libraries that use special
introspection mechanisms to generate language bindings, e.g. GObject.

Re: The Strange Loop conference

[Timon Gehr]

On 09/21/2011 06:55 PM, Andrei Alexandrescu wrote:

I'm back from the Strange Loop conference. It's been an interesting
experience. The audience was very diverse, with interest in everything
functional (you'd only need to say "Haskell" or "monad" to get positive
aahs), Web/cloud/tablet stuff, concurrent and distributed systems.
Mentioning C++ non-mockingly was all but a faux pas; languages like
Scala, Haskell, Clojure, and Erlang got attention. The quality of talks
has been very variable, and unfortunately the
over-confident-but-clueless-speaker stereotype was well represented.

I gave a talk there
(https://thestrangeloop.com/sessions/generic-programming-galore-using-d)
which has enjoyed moderate audience and success. I uploaded the slides
at http://erdani.com/d/generic-programming-galore.pdf and the video may
be available soon.


I am looking forward to it!



There was a very strong interest in D's CTFE abilities, which we should
consider a strategic direction going forward.


One milestone would be to make DMD GC enabled. CTFE string manipulation 
sucks up too much memory.



Also finalizing D's
concurrency language and library infrastructure is essential. These two
features are key differentiators. Also, capitalizing on D's functional
features (which are e.g. better than Scala's but less known) would add
good value.



Where D still loses when compared to Scala is functional code syntax:

val newcol = collection filter {x=>x<5} map {x=>2*x}

or maybe

val newcol = for(x<-collection if(x<5)) yield 2*x

vs

auto newrange = filter!((x){return x<5;})(map!((x){return 2*x;})(range));

I believe that is part of the reason why it is less known. If I write 
functional style code in D I unfortunately usually get feedback that it 
is "extremely hard to read". Furthermore, Scala has built-in tuples, and 
eg delimited continuations, which enable some more functional 
programming idioms. std.algorithm/std.range are also considerably (and 
as I understand, deliberately) underpowered for FP when compared to eg 
Haskell's standard set of libraries, and writing a good range from 
scratch is usually a serious undertaking.


Another big advantage that Scala has is that it supports pattern 
matching. It is usually about the first feature functional programmers 
care about.


What do you think is the biggest advantage that Ds functional 
programming has in comparison to Scala's?

Re: Paradox about D's popularity.

[Gor F. Gyolchanyan]

As much as I'd like D to develop sweet language features like named function
parameters, directing effort to increase compatibility of D with other languages
(most notably, C++) would be a better idea, because if D gets cheaper and 
cheaper
to use with existing code base, more and more people will start caring about D 
and
the aforementioned sweet language features will get implemented more rapidly.

If Walter, Andrei and others agree with my proposal, i suggest to postpone all
enhancement requests for D, except compatibility-related ones and direct all our
attention to it. As well as direct more attention towards fixing DMD bugs, 
rather
then developing phobos libraries, because as much as developing phobos is
important, having a stable compiler is much more important.

Re: D's confusing strings (was Re: D on hackernews)

[Christophe]

"Simen Kjaeraas" , dans le message (digitalmars.D:144921), a écrit :
> What you are thinking about is a code point.

Yes, sorry. Then I disagree with "as long as char is a unicode code 
unit, that's the way that it goes", since myString.front should then 
return a code unit, whereas it actually returns a code point.

>> Unicode operations should be supported by a different class that
>> is really a lazy range of dchar implemented as an undelying char[], with
>> no length, index, or stride operator, and appropriate optimizations.
> 
> I can agree with this, but the benefits over what we already have are nigh
> zilch.

I think no one here as any illusion about changing this in D2.

However, this class could be introduced in phobos right now, without 
changing anything about string. It would simply be a bit safer than 
strings.

-- 
Christophe

Re: Paradox about D's popularity.

[Gor F. Gyolchanyan]

I'll look up any kind of programming language related sites and try to put D put
there.

Another big downside, that i noticed in development of D and DMD is
unpredictability. I think we should make schedules for regular releases of 
batches
of bug-fixes and feature enhancements of DMD, so that people will be able to use
yet-unimplemented features of they're certainly going to be implemented in the
next release.

Also in the light of recent investigation, i think it would be very wise to turn
our attention to enhance D's compatibility with C++, since this is one of the
biggest problems, that companies will face if they decide to switch to D. If D
gains a good enough compatibility with C++ (i know, it's a really difficult 
job),
then the cost of switching to D will dramatically decrease, because less and 
less
C++ code will need to be rewritten. For those cases when direct access to C++ is
impossible (probably, with multiple inheritance involved), we could make D
libraries, that would interpret C++ headers at compile time and generate 
wrappers
around it (and such).
It'll take a lot of effort, but it's possible and given the current situation of
commercial non-usability of D it would be a good idea.

Re: D's confusing strings (was Re: D on hackernews)

[Jonathan M Davis]

On Wednesday, September 21, 2011 11:20 Christophe Travert wrote:
> Jonathan M Davis , dans le message (digitalmars.D:144896), a écrit :
> > On Wednesday, September 21, 2011 15:16:33 Christophe wrote:
> >> Timon Gehr , dans le message (digitalmars.D:144889), a écrit :
> >> > unicode natively. Yet the 'D strings are strange and confusing'
> >> > argument comes up quite often on the web.
> >> 
> >> Well, I think they are. The ptr+length stuff is amasing, but the
> >> behavior of strings in phobos is weird.
> >> 
> >> mini-quiz: what should std.range.drop(some_string, 1) do ?
> >> hint: what it actually does is not what the documentation of phobos
> >> suggests*...
> > 
> > What do you mean? It does exactly what it says that it does.
> 
> It does say it uses the slice operator if the range is sliceable, and
> the documentation to isSliceable fails to precise that a narrow string
> is not sliceable.

1. drop says nothing about slicing.
2. popFrontN (which drop calls) says that it slices for ranges that support 
slicing. Strings do not unless they're arrays of dchar.

Yes, hasSlicing should probably be clearer about narrow strings, but that has 
nothing to do with drop.

> > Yeah, well, as long as char is a unicode code unit, that's the way that
> > it goes.
> 
> They are not unicode units.
> 
> void main() {
> char a = 'ä';
> writeln(a); // outputs: \344
> writeln('ä'); // outputs: ä
> }
> 
> Obviouly, a code unit don't fit in a char.
> Thus 'char[]' is not what the name claims it is.
> 
> Unicode operations should be supported by a different class that
> is really a lazy range of dchar implemented as an undelying char[], with
> no length, index, or stride operator, and appropriate optimizations.

The problem with

char a = 'ä';

is completely separate from char[]. That has to do with the fact that the 
compiler isn't properly dealing with narrowing conversions for an individual 
character. A char is _by definition_ a UTF-8 code unit. 

char a = 'ä';

shouldn't even be legal. It's a compiler bug. Most code which operates on 
individual chars or wchars is buggy. dchar is what should be used for 
individual characters. The code you give is buggy because it's trying to use 
char as individual character, and the compiler has a bug, so it doesn't catch 
it.

> > In general, Phobos does a good job of using slicing and other
> > optimizations on strings when it can in spite of the fact that they're
> > not sliceable ranges, but there are cases where the fact that you _have_
> > to process them to be able to find the nth code point means that you
> > just can't process them as efficiently as your typical array. That's
> > life with a variable- length encoding. - and that includes
> > std.algorithm.copy. But that's an easy one to get around, since if you
> > wanted to ignore unicode safety and just copy some chunk of the string,
> > you can always just slice it directly with no need for copy.
> 
> Dealing with utfencoded strings is less efficient, but there is a number
> of algorithms that can be optimized for utfencoded strings, like copying
> or finding an ascii char in a string. Unfortunately, there is no
> practical way to do this with the current range API.
>
> About copy, it's not that easy to overcome the problem if you are using
> a template, and that template happens to be instanciated for strings.

In general, you _must_ treat strings as ranges of dchar if you want your code 
to be correct with regards to code points. So, that's the default. If you know 
that your particular algorithm can be optimized for strings without treating 
them strictly as ranges of dchar and still deal with unicode correctly (e.g. 
by slicing them, because you know the correct point to slice to), then you 
special-case your template for narrow strings. Phobos does that in a number of 
places. But you _have_ to special case it because being able to do so depends 
entirely on your algorithm. You can't treat strings that way in the general 
case, or yor code is not going to handle unicode correctly.

No, the way that strings are handled in D is not perfect. But we're trying to 
balance correctness and efficiency, and it does a good job of that. Using 
strings as ranges of dchar is correct, and in a large number of cases, it is 
as efficient as your going to get it (perhaps particular functions could be 
better optimized, but the API can't be made more efficient). And in the cases 
where you know you can safely get better efficiency out of strings by special 
casing them, that's what you do. It works. It works fairly well. And no one 
has been able to come up with a solution that's definitely better.

If there's an issue, it's that the message on how to correctly handle strings 
is not necessarily being communicated as well as it needs to be. In a few 
places, the documentation could probably be improved, but what we probobly 
really need in order to help get the message across is more articles on ranges 
and strings as ranges. I've actua

Re: C compatibility module for phobos.

[Gor F. Gyolchanyan]

I didn't know about core.stdc package because it doesn't show u on dpl.org.

The difference is, that some compilers make long 64 bit for 64-bit systems, and
some leave the long 32-bit no matter what.

Re: D's confusing strings (was Re: D on hackernews)

[Simen Kjaeraas]

On Wed, 21 Sep 2011 20:20:55 +0200, Christophe Travert  
 wrote:



Yeah, well, as long as char is a unicode code unit, that's the way that  
it

goes.


They are not unicode units.

void main() {
  char a = 'ä';
  writeln(a); // outputs: \344
  writeln('ä'); // outputs: ä
}

Obviouly, a code unit don't fit in a char.
Thus 'char[]' is not what the name claims it is.


Oh, it absolutely is. According to the Unicode Consortium, A code unit is
"The minimal bit combination that can represent a unit of encoded text
for processing or interchange. The Unicode Standard uses 8-bit code units
in the UTF-8 encoding form [...]".

What you are thinking about is a code point.



Unicode operations should be supported by a different class that
is really a lazy range of dchar implemented as an undelying char[], with
no length, index, or stride operator, and appropriate optimizations.


I can agree with this, but the benefits over what we already have are nigh
zilch.


--
  Simen

Re: D's confusing strings (was Re: D on hackernews)

[Peter Alexander]

On 21/09/11 5:39 PM, Andrei Alexandrescu wrote:

On 9/21/11 10:16 AM, Christophe wrote:

Timon Gehr , dans le message (digitalmars.D:144889), a écrit :

unicode natively. Yet the 'D strings are strange and confusing' argument
comes up quite often on the web.


Well, I think they are. The ptr+length stuff is amasing, but the
behavior of strings in phobos is weird.

mini-quiz: what should std.range.drop(some_string, 1) do ?
hint: what it actually does is not what the documentation of phobos
suggests*...

Strings are array of char, but they appear like a lazy range of dchar to
phobos. I could cope with the fact that this is a little unexpected for
beginners. But well, that creates a lot of exceptions in phobos, like
the fact that you can't even copy a char[] to a char[] with
std.algorithm.copy. And I don't mention all the optimization that are
not/cannot be performed for those strings. I'll just remember to use
ubyte[] wherever I can...


String handling in D is good modulo the oddities you noticed. What would
make it perfect would be:

* Add property .rep that returns byte[], ushort[], or uint[] for char[],
wchar[], dchar[] respectively (with the appropriate qualifier).

* Replace .length with .codeUnits.

* Disallow [n] and [m .. n]

This would upgrade D's strings from good to awesome. Really it would be
a dream come true. Unfortunately it would also break most D code there
is out there. I don't see how we can improve the current situation while
staying backward compatible.


Andrei


From what I can see, the problem with D string is that they are a 
'magic' special case for arrays.


char[] should be an array of char, just like int[] is an array of int. 
If you have a T[] arr, then typeof(arr.front) should be T. This is what 
everyone would expect. char[] should essentially be the same as byte[], 
although char[] would be more natural for ASCII strings.


string should be something different, a separate type. As you say, 
disallow [n] and [m..n] would be good as they make no sense with VLE. 
You could have .length and .codeUnits, but length would have to be O(n). 
That's not ideal, but since string wouldn't be an array, it doesn't need 
to have the same complexity guarantees.


Same for wchar[], dchar[], wstring and dstring.

Of course, making that change would break existing code. Maybe D3? :-)

Re: C compatibility module for phobos.

[Gor F. Gyolchanyan]

Thanks! I never new that module existed! It's not mentioned in dpl.org.

Re: C compatibility module for phobos.

[Gor F. Gyolchanyan]

Will do! :-)
Right after i take a look at the existing core.stdc.config module, that i never
knew about before :-)

Re: C compatibility module for phobos.

[Jesse Phillips]

Gor Gyolchanyan Wrote:

> Hello, my dear, beloved D community.
> 
> I've been reading literally all discussions on D.puremagic.com for about a
> month now and I'm deeply concerned with my favorite language and it's
> reference compiler.
> 
> So, for starters, i decided to add a very useful (in my opinion) module to
> phobos: etc.c.compat.
> 
> Here's the pull request:
> https://github.com/D-Programming-Language/phobos/pull/265
> 
> This module is supposed to help people develop bindings for C libraries, by
> providing information language-specific information, depending on certain
> compiler, processor architecture, operating system, etc.
> 
> Currently there are only aliases for C built-in types, which are static
> if-ed to have the correct size for the respective C compilers.

Isn't this almost exactly like stdint

https://github.com/D-Programming-Language/druntime/blob/master/src/core/stdc/stdint.d

except that it isn't based on target architecture and can specify specific 
compilers? Also how much do sizes differ between compilers?

Re: Go and generic programming on reddit, also touches on D

[Don]

On 19.09.2011 18:12, Andrei Alexandrescu wrote:

On 9/19/11 10:46 AM, Robert Jacques wrote:

So, on balance, I'd say the two pointers representation is categorically
worse than the fat pointer representation.


Benchmark. A few of your assumptions don't hold.

Andrei


Note that high-performance libraries that use slices, like GMP and the 
many BLAS libraries, use the pointer+length representation, not 
pointer+pointer. They've done a lot of benchmarking on a huge range of 
architectures, with a large range of compilers.


The underlying reason for this, is that almost all CISC instruction sets 
have built-in support for pointer+length. AFAIK nothing has builtin 
support for ptr+ptr.


On x86, you have this wonderful [EAX+8*EBX] addressing mode, that can be 
used on almost every instruction, so that the calculation [addr + 
sz*index] takes ZERO clock cycles when sz is a power of 2.
Generally, when you supply two pointers, the optimizer will try to 
convert it into ptr + offset (where offset isn't bytes, it corresponds 
to D's length).

Re: C compatibility module for phobos.

[Alex Rønne Petersen]

On 21-09-2011 10:01, Gor Gyolchanyan wrote:

Hello, my dear, beloved D community.

I've been reading literally all discussions on D.puremagic.com
 for about a month now and I'm deeply concerned
with my favorite language and it's reference compiler.

So, for starters, i decided to add a very useful (in my opinion) module
to phobos: etc.c.compat.

Here's the pull request:
https://github.com/D-Programming-Language/phobos/pull/265

This module is supposed to help people develop bindings for C libraries,
by providing information language-specific information, depending on
certain compiler, processor architecture, operating system, etc.

Currently there are only aliases for C built-in types, which are static
if-ed to have the correct size for the respective C compilers.

It's well-documented and waits to be enhanced with more accurate
compile-time branching and additional useful information to make binding
C code even easier.

If we get a good enough C compatibility module, we'll be able to rapidly
bind all major and frequently-used libraries and include them in phobos.

This will also do a great job of promoting D as a good language to adopt
for serious projects, because it's standard library will be very rich
and common usage won't require the programmer to resort to anything
besides phobos.

Any comments would be much appreciated.


Hi,

You should probably fix the enum member names to use camelCase (though 
in the case of 'x86_64', I think the underscore is acceptable).


- Alex

Re: Why did D leave the programming language shootout and will it return?

[Peter Alexander]

On 21/09/11 12:58 AM, Timon Gehr wrote:

On 09/21/2011 01:37 AM, Walter Bright wrote:

(In contrast, C++ must invoke the copy constructor.)


C++11 rvalue references manage to make that effect somewhat less painful
though.


Less expensive computationally, yes, but the cost to the programmer is huge.

I'm willing to bet that the % of professional C++ programmers that could 
write (for example) std::vector, using move and copy semantics 
correctly, with all the correctness and exception safety guarantees, is 
incredibly low -- probably less than 1%.


In D, you just memcpy most of the time. It makes things so much easier.

And what do you lose? Internal pointers?

Who cares about internal pointers? They are so rarely used and easily 
replaceable that the overwhelming cost of supporting them is completely 
unjustified.


The disallowing of internal pointers is easily my #1 favourite feature of D.

Re: Aligning data in memory

[Peter Alexander]

I could be wrong, but I think so.

As I understand, align(N) only aligns it *within the structure*.

If you are at 0 offset, you are aligned on all N already, so I don't see 
why it would add padding before the first member of a struct.



On 21/09/11 11:22 AM, Rory McGuire wrote:

Would that even be true in the case where you specify a alignment (
keeping in mind that the alignment is for that specific variable)?



On Tue, Sep 20, 2011 at 7:25 PM, Peter Alexander
mailto:peter.alexander...@gmail.com>> wrote:

On 19/09/11 9:17 AM, Rory McGuire wrote:

surely you would have to use
  movaps XMM0, v.v;

  because the alignment would only happen inside the struct?


On Sat, Sep 17, 2011 at 8:11 PM, Adam D. Ruppe
mailto:destructiona...@gmail.com>
>> wrote:

Perhaps:

void foo() {
struct V { align(16) float[4] v = [1.0f, 2.0f, 3.0f,
4.0f]; }
V v;
asm {
movaps XMM0, v;
}
}


It compiles, but I'm not sure if it's actually correct.



v has offset 0 in the struct, so &v.v == &v, which is all the inline
asm cares about.

Re: D's confusing strings (was Re: D on hackernews)

[Christophe Travert]

Jonathan M Davis , dans le message (digitalmars.D:144896), a écrit :
> On Wednesday, September 21, 2011 15:16:33 Christophe wrote:
>> Timon Gehr , dans le message (digitalmars.D:144889), a écrit :
>> > unicode natively. Yet the 'D strings are strange and confusing' argument
>> > comes up quite often on the web.
>> 
>> Well, I think they are. The ptr+length stuff is amasing, but the
>> behavior of strings in phobos is weird.
>> 
>> mini-quiz: what should std.range.drop(some_string, 1) do ?
>> hint: what it actually does is not what the documentation of phobos
>> suggests*...
> 
> What do you mean? It does exactly what it says that it does.

It does say it uses the slice operator if the range is sliceable, and
the documentation to isSliceable fails to precise that a narrow string 
is not sliceable.

> Yeah, well, as long as char is a unicode code unit, that's the way that it 
> goes.

They are not unicode units.

void main() {
  char a = 'ä';
  writeln(a); // outputs: \344
  writeln('ä'); // outputs: ä
}

Obviouly, a code unit don't fit in a char.
Thus 'char[]' is not what the name claims it is.

Unicode operations should be supported by a different class that 
is really a lazy range of dchar implemented as an undelying char[], with 
no length, index, or stride operator, and appropriate optimizations.

> In general, Phobos does a good job of using slicing and other 
> optimizations on strings when it can in spite of the fact that they're not 
> sliceable ranges, but there are cases where the fact that you _have_ to 
> process them to be able to find the nth code point means that you just can't 
> process them as efficiently as your typical array. That's life with a 
> variable-
> length encoding. - and that includes std.algorithm.copy. But that's an easy 
> one 
> to get around, since if you wanted to ignore unicode safety and just copy 
> some 
> chunk of the string, you can always just slice it directly with no need for 
> copy.

Dealing with utfencoded strings is less efficient, but there is a number 
of algorithms that can be optimized for utfencoded strings, like copying 
or finding an ascii char in a string. Unfortunately, there is no 
practical way to do this with the current range API.

About copy, it's not that easy to overcome the problem if you are using 
a template, and that template happens to be instanciated for strings.

>> * Please, someone just adds in the documentation of IsSliceable that
>> narrow strings are an exception, like it was recently added to
>> hasLength.
> 
> A good point.

The main point of my post actually.

-- 
Christophe

Re: The Strange Loop conference

[bearophile]

Andrei Alexandrescu:

> which has enjoyed moderate audience and success. I uploaded the slides 
> at http://erdani.com/d/generic-programming-galore.pdf and the video may 
> be available soon.

In future talks I suggest to show some downsides too, like explaining how much 
memory uses the D RE engine, how hard are to write, read, modify and debug 
text-based mixins like the bitfields, etc. In my opinion if you only show the 
upsides of something, probably even average programmers become suspicious.

Bye,
bearophile

Re: Paradox about D's popularity.

[bearophile]

Gor Gyolchanyan:

> I'm ready to donate money to sponsor an ad campaign.

Advertising has to be done at the right time and rhythm. Too little and no one 
knows you, too much and you risk wasting the single opportunity certain persons 
will give you. D doesn't need too much advertising now. There is not even a 
hash map in Phobos and there are some unfinished parts in the core language, 
like inout, const, modules, associative arrays, etc.

Bye,
bearophile

Re: Paradox about D's popularity.

[J Arrizza]

All excellent points Gor.

I'd like to point out that Java faced nearly the same issues (one difference
is it had Sun backing it) and yet it overcame those hurdles.

I believe it became as popular as it did because of the JDK, not because of
the language itself. (I actually called v1.0 a "toy language" :) The
decisions by individual companies to use Java were tipped in its favor
because so much free code is available in the JDK. There was a cost/benefit
analysis done: the overall time to write new or convert old applications is
going to be less than the additional time required to learn the new language
, new tools, overcome bugs, etc., therefore go with Java. From a managerial
point of view, it's simple: less code my team writes => better.

Having said that, D is, in my opinion, ripe for creating a full featured
development suite (DeeDk?). A lot of the language features themselves
clearly support library writers in much better ways than Java. Of course, it
is an overwhelming amount of work...

John


On Wed, Sep 21, 2011 at 2:18 AM, Gor Gyolchanyan <
gor.f.gyolchan...@gmail.com> wrote:

> Preface:
>
> Back when i didn't know about D's existence, C++ was my favorite language.
>

Re: Paradox about D's popularity.

[Andrei Alexandrescu]

On 9/21/11 4:18 AM, Gor Gyolchanyan wrote:
[snip]

D is maintained by a group of volunteers (I've joined that group
recently), with no commercial interest in it. Of course, that's good,
but not too reassuring.

I call upon all fellow D developers to help me put together a reasonable
infrastructure for D and end this annoying popularity paradox once and
for all.
As well as try to spread awareness of D as much as possible using ads,
reviews, benchmarks and anything else that people tend to read once in a
while.

I'm ready to donate money to sponsor an ad campaign.


Nice, enthusiastic initiative. I think you started in the right vein by 
contributing to our github code base. Looking forward to more to come.


One simple thing that could improve D's PR would be mirroring the 
Shootout benchmarks for D. Right now D is not present on the Shootout 
site, but the benchmarks are open-sourced and their use is encouraged by 
the author.


Once we have a setup for the benchmarks, we'd have a good basis to 
kindly ask the site maintainer to add back D to the suite.



Andrei

Why do we have transitive const, again?

[Mehrdad]

I can't find the thread, but I remember someone (bearophile?) mentioned 
that the reason we have transitive const is to support purity.


I don't think I understand why this is necessary, though -- could 
someone please explain why we have transitive const, and what problems 
it fixes?


Thanks!

Re: D's confusing strings (was Re: D on hackernews)

[Graham Fawcett]

On Wed, 21 Sep 2011 11:39:03 -0500, Andrei Alexandrescu wrote:

> On 9/21/11 10:16 AM, Christophe wrote:
>> Timon Gehr , dans le message (digitalmars.D:144889), a écrit :
>>> unicode natively. Yet the 'D strings are strange and confusing'
>>> argument comes up quite often on the web.
>>
>> Well, I think they are. The ptr+length stuff is amasing, but the
>> behavior of strings in phobos is weird.
>>
>> mini-quiz: what should std.range.drop(some_string, 1) do ? hint: what
>> it actually does is not what the documentation of phobos suggests*...
>>
>> Strings are array of char, but they appear like a lazy range of dchar
>> to phobos. I could cope with the fact that this is a little unexpected
>> for beginners. But well, that creates a lot of exceptions in phobos,
>> like the fact that you can't even copy a char[] to a char[] with
>> std.algorithm.copy. And I don't mention all the optimization that are
>> not/cannot be performed for those strings. I'll just remember to use
>> ubyte[] wherever I can...
> 
> String handling in D is good modulo the oddities you noticed. What would
> make it perfect would be:
> 
> * Add property .rep that returns byte[], ushort[], or uint[] for char[],
> wchar[], dchar[] respectively (with the appropriate qualifier).
> 
> * Replace .length with .codeUnits.
> 
> * Disallow [n] and [m .. n]
> 
> This would upgrade D's strings from good to awesome. Really it would be
> a dream come true. Unfortunately it would also break most D code there
> is out there. I don't see how we can improve the current situation while
> staying backward compatible.
> 
> 
> Andrei

1. Let "string" remain an alias for "immutable(char)[]", and introduce a 
new struct, "text!charType", that does the awesome stuff; provide good 
conversion routines and casts between text instances and old-school 
strings.

2. Provide an awesome "std.text" library for the text type and related 
operations, absorbing std.uni and other similar modules. Adapt Phobos to 
take "text" in virtually every function that currently expects a "string".

3. ...

4. Profit.

Graham

Re: C compatibility module for phobos.

[Sean Kelly]

You might want to look at core.stdc.config. It contains the essential 
compatibility stuff for interfacing with C. 

Sent from my iPhone

On Sep 21, 2011, at 1:01 AM, Gor Gyolchanyan  
wrote:

> Hello, my dear, beloved D community.
> 
> I've been reading literally all discussions on D.puremagic.com for about a 
> month now and I'm deeply concerned with my favorite language and it's 
> reference compiler.
> 
> So, for starters, i decided to add a very useful (in my opinion) module to 
> phobos: etc.c.compat.
> 
> Here's the pull request: 
> https://github.com/D-Programming-Language/phobos/pull/265
> 
> This module is supposed to help people develop bindings for C libraries, by 
> providing information language-specific information, depending on certain 
> compiler, processor architecture, operating system, etc.
> 
> Currently there are only aliases for C built-in types, which are static if-ed 
> to have the correct size for the respective C compilers.
> 
> It's well-documented and waits to be enhanced with more accurate compile-time 
> branching and additional useful information to make binding C code even 
> easier.
> 
> If we get a good enough C compatibility module, we'll be able to rapidly bind 
> all major and frequently-used libraries and include them in phobos.
> 
> This will also do a great job of promoting D as a good language to adopt for 
> serious projects, because it's standard library will be very rich and common 
> usage won't require the programmer to resort to anything besides phobos.
> 
> Any comments would be much appreciated.

The Strange Loop conference

[Andrei Alexandrescu]

I'm back from the Strange Loop conference. It's been an interesting 
experience. The audience was very diverse, with interest in everything 
functional (you'd only need to say "Haskell" or "monad" to get positive 
aahs), Web/cloud/tablet stuff, concurrent and distributed systems. 
Mentioning C++ non-mockingly was all but a faux pas; languages like 
Scala, Haskell, Clojure, and Erlang got attention. The quality of talks 
has been very variable, and unfortunately the 
over-confident-but-clueless-speaker stereotype was well represented.


I gave a talk there 
(https://thestrangeloop.com/sessions/generic-programming-galore-using-d) 
which has enjoyed moderate audience and success. I uploaded the slides 
at http://erdani.com/d/generic-programming-galore.pdf and the video may 
be available soon.


There was a very strong interest in D's CTFE abilities, which we should 
consider a strategic direction going forward. Also finalizing D's 
concurrency language and library infrastructure is essential. These two 
features are key differentiators. Also, capitalizing on D's functional 
features (which are e.g. better than Scala's but less known) would add 
good value.



Thanks,

Andrei

C compatibility module for phobos.

[Gor Gyolchanyan]

Hello, my dear, beloved D community.

I've been reading literally all discussions on D.puremagic.com for about a
month now and I'm deeply concerned with my favorite language and it's
reference compiler.

So, for starters, i decided to add a very useful (in my opinion) module to
phobos: etc.c.compat.

Here's the pull request:
https://github.com/D-Programming-Language/phobos/pull/265

This module is supposed to help people develop bindings for C libraries, by
providing information language-specific information, depending on certain
compiler, processor architecture, operating system, etc.

Currently there are only aliases for C built-in types, which are static
if-ed to have the correct size for the respective C compilers.

It's well-documented and waits to be enhanced with more accurate
compile-time branching and additional useful information to make binding C
code even easier.

If we get a good enough C compatibility module, we'll be able to rapidly
bind all major and frequently-used libraries and include them in phobos.

This will also do a great job of promoting D as a good language to adopt for
serious projects, because it's standard library will be very rich and common
usage won't require the programmer to resort to anything besides phobos.

Any comments would be much appreciated.

Paradox about D's popularity.

[Gor Gyolchanyan]

Preface:

Back when i didn't know about D's existence, C++ was my favorite language.
The reason for that was, that C++ allowed all the following simultaneously:
* Allowed me to wrote very optimized and high-performance code (I'm a
run-time performance paranoiac).
* Allowed me to avoid constant low-level shenanigans (what with
object-oriented and/or generic programming wrappers and all).
* Allowed me to project my problem space into solution space relatively
easily.
And the complexity and downsides of C++ were essentially ignored because
"Well, i can cope with that, so what's the problem?".
The high-productivity alternatives to C++, like Java could never quench my
paranoid thirst for run-time performance, so i was basically stuck with C++.
Sometimes i realized, that having high-productivity and high run-time
performance simultaneously was impossible, which killed my passion for
programming.
Then D comes along...
I take a close look at it and I fell in love with it!
Not only does it perfectly satisfy my run-time performance paranoia, but it
looks so beautiful and it's so simple!
D re-ignited fires of passion to programming in me!
It objectively has no practical weakness against C++.

Main point:

I've conducted an experiment by promoting D to my colleagues. Every single
conversation ended up like "Well, i don't deny it's superiority, but we're
not gonna rewrite our code base anyway".
I further investigated  the "Why would you wanna spend lots of time and
money on maintaining old crotchety code, rather then re-investing the same
money in PARTIALLY rewriting the code base and forget about troubles
forever?".
It turns out, that people, who maintain mature commercial projects are
simply afraid to switch from their language.
Note, that they're not afraid to switch to D, their afraid to switch from
C++.
This is because they have 100% confidence in C++ in terms of it's support,
tools, libraries and general usability.
They KNOW, that they'll always have stable compiler, IDE, libraries and lots
of C++ experts to help them with language-related issues.

Currently, D has none of those things. D is, as i said earlier, an amazingly
beautiful and powerful language, which nobody denies, but it has no stable
compiler (DMD is full of bugs, GDC and LDC inherit DMD's bugs and all that
stops me from using D to it's full extent), it has no satisfying IDEs
(VisualD and DDT are the only ones and are also full of bugs) and library
(All D has is a tiny little phobos and a couple of broken bindings for D1).

And above all, people gain confidence int a language if it's being actively
breast-fed by a big fat company. Example: C++ is being taken care of by
Microsoft in the form of active development of their compiler, public
documentation about it and a whole lot of action going on around C++. And
average Joe thinks "Toy can't miss with Microsoft!" and goes ahead and uses
C++.

D is maintained by a group of volunteers (I've joined that group recently),
with no commercial interest in it. Of course, that's good, but not too
reassuring.

I call upon all fellow D developers to help me put together a reasonable
infrastructure for D and end this annoying popularity paradox once and for
all.
As well as try to spread awareness of D as much as possible using ads,
reviews, benchmarks and anything else that people tend to read once in a
while.

I'm ready to donate money to sponsor an ad campaign.

Re: Is there a CPAN, CheeseShop, Hackage or NPM for D?

[Jacob Carlborg]

On 2011-09-20 13:37, Chris Dew wrote:

Hi Jacob,

It's great to see that someone's working on this.

Will your design cope with the situation as follows:

ModA 1.0.0 requires ModB>=1.0.0<2.0.0 and ModC>=1.0.0<2.0.0
ModB 1.0.0 requires ModD>=1.0.0<2.0.0
ModC 1.0.0 requires ModD>=2.0.0<3.0.0
ModD 1.0.0 and 2.0.0 are both available with different interfaces and semantics.

Could I recommend SemVer? http://semver.org/

Thanks,

Chris.



I'm already using that (or something very similar): 
https://github.com/jacob-carlborg/orbit/wiki/orb%20package#wiki-versions


--
/Jacob Carlborg

Re: D's confusing strings (was Re: D on hackernews)

[Andrei Alexandrescu]

On 9/21/11 10:16 AM, Christophe wrote:

Timon Gehr , dans le message (digitalmars.D:144889), a écrit :

unicode natively. Yet the 'D strings are strange and confusing' argument
comes up quite often on the web.


Well, I think they are. The ptr+length stuff is amasing, but the
behavior of strings in phobos is weird.

mini-quiz: what should std.range.drop(some_string, 1) do ?
hint: what it actually does is not what the documentation of phobos
suggests*...

Strings are array of char, but they appear like a lazy range of dchar to
phobos. I could cope with the fact that this is a little unexpected for
beginners. But well, that creates a lot of exceptions in phobos, like
the fact that you can't even copy a char[] to a char[] with
std.algorithm.copy. And I don't mention all the optimization that are
not/cannot be performed for those strings. I'll just remember to use
ubyte[] wherever I can...


String handling in D is good modulo the oddities you noticed. What would 
make it perfect would be:


* Add property .rep that returns byte[], ushort[], or uint[] for char[], 
wchar[], dchar[] respectively (with the appropriate qualifier).


* Replace .length with .codeUnits.

* Disallow [n] and [m .. n]

This would upgrade D's strings from good to awesome. Really it would be 
a dream come true. Unfortunately it would also break most D code there 
is out there. I don't see how we can improve the current situation while 
staying backward compatible.



Andrei

Re: D on hackernews

[Jacob Carlborg]

On 2011-09-21 15:52, Timon Gehr wrote:

On 09/21/2011 09:37 AM, bearophile wrote:

Andrei Alexandrescu:


http://hackerne.ws/item?id=3014861

Apparently we're still having a PR issue.


I think the Wikipedia D page needs to be rewritten, leaving 80-90% of
its space to D (meaning D2).



Yes, that is important. Wikipedia is usually the first place people go
looking for information, and much of the information given there is
horribly outdated/wrong and mostly only concerns. Many people think
what's on Wikipedia is true. [citation needed]

"For performance reasons, string slicing and the length property operate
on code units rather than code points (characters), which frequently
confuses developers.[27]"

The link at [27] only says that many programmers that don't had have to
handle unicode have trouble understanding how unicode works initially.
It is not a D thing in any other way than that D actually supports
unicode natively. Yet the 'D strings are strange and confusing' argument
comes up quite often on the web, probably because many feel they are
competent enough to discuss the language after having read the Wikipedia
article.


Ruby pre 1.9 behaves similar. Well, actually Ruby pre 1.9 is not 
encoding aware at all, if I recall correctly.


--
/Jacob Carlborg

Re: Good publicity for D on heise/developer

[Andrej Mitrovic]

And there's a German D1 e-book here (140 pages!):
http://web.archive.org/web/20070930135319/http://www.steinmole.de/d/d_buch.pdf

Pretty cool.

Re: D's confusing strings (was Re: D on hackernews)

[Jonathan M Davis]

On Wednesday, September 21, 2011 15:16:33 Christophe wrote:
> Timon Gehr , dans le message (digitalmars.D:144889), a écrit :
> > unicode natively. Yet the 'D strings are strange and confusing' argument
> > comes up quite often on the web.
> 
> Well, I think they are. The ptr+length stuff is amasing, but the
> behavior of strings in phobos is weird.
> 
> mini-quiz: what should std.range.drop(some_string, 1) do ?
> hint: what it actually does is not what the documentation of phobos
> suggests*...

What do you mean? It does exactly what it says that it does.

> Strings are array of char, but they appear like a lazy range of dchar to
> phobos. I could cope with the fact that this is a little unexpected for
> beginners. But well, that creates a lot of exceptions in phobos, like
> the fact that you can't even copy a char[] to a char[] with
> std.algorithm.copy. And I don't mention all the optimization that are
> not/cannot be performed for those strings. I'll just remember to use
> ubyte[] wherever I can...

Yeah, well, as long as char is a unicode code unit, that's the way that it 
goes. In general, Phobos does a good job of using slicing and other 
optimizations on strings when it can in spite of the fact that they're not 
sliceable ranges, but there are cases where the fact that you _have_ to 
process them to be able to find the nth code point means that you just can't 
process them as efficiently as your typical array. That's life with a variable-
length encoding - and that includes std.algorithm.copy. But that's an easy one 
to get around, since if you wanted to ignore unicode safety and just copy some 
chunk of the string, you can always just slice it directly with no need for 
copy.

> * Please, someone just adds in the documentation of IsSliceable that
> narrow strings are an exception, like it was recently added to
> hasLength.

A good point.

- Jonathan M Davis

Re: Good publicity for D on heise/developer

[Andrej Mitrovic]

Interesting, there's also this older (dated 2008) D-specific article:
http://www.heise.de/developer/artikel/D-die-neue-Programmiersprache-mit-C-Wurzeln-227070.html

Autotranslation isn't too good but it's bearable:
http://translate.google.com/translate?sl=auto&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fwww.heise.de%2Fdeveloper%2Fartikel%2FD-die-neue-Programmiersprache-mit-C-Wurzeln-227070.html

Good publicity for D on heise/developer

[Tobias Pankrath]

Heise is one of the biggest publisher for IT related magazines and
news in Germany. Their branch heise Developer targets (nomen est omen) 
software engineers specifically. 

They published an article about C++0xb recently. You can find it here.
http://www.heise.de/developer/artikel/C-11-auch-ein-
Stimmungsbild-1345406.html

Throughout the article the author always mentions D as an alternative, 
when talks about strengths of C++.

For example he says:
> This are areas [SSE] where only C/C++ and D can shine.

And calls D the "clean C++ alternative".

D's confusing strings (was Re: D on hackernews)

[Christophe]

Timon Gehr , dans le message (digitalmars.D:144889), a écrit :
> unicode natively. Yet the 'D strings are strange and confusing' argument 
> comes up quite often on the web.

Well, I think they are. The ptr+length stuff is amasing, but the 
behavior of strings in phobos is weird.

mini-quiz: what should std.range.drop(some_string, 1) do ?
hint: what it actually does is not what the documentation of phobos 
suggests*...

Strings are array of char, but they appear like a lazy range of dchar to 
phobos. I could cope with the fact that this is a little unexpected for 
beginners. But well, that creates a lot of exceptions in phobos, like 
the fact that you can't even copy a char[] to a char[] with 
std.algorithm.copy. And I don't mention all the optimization that are 
not/cannot be performed for those strings. I'll just remember to use 
ubyte[] wherever I can...

* Please, someone just adds in the documentation of IsSliceable that 
narrow strings are an exception, like it was recently added to 
hasLength.

-- 
Christophe

Re: D on hackernews

[Timon Gehr]

On 09/21/2011 03:52 PM, Timon Gehr wrote:

On 09/21/2011 09:37 AM, bearophile wrote:

Andrei Alexandrescu:


http://hackerne.ws/item?id=3014861

Apparently we're still having a PR issue.


I think the Wikipedia D page needs to be rewritten, leaving 80-90% of
its space to D (meaning D2).



Yes, that is important. Wikipedia is usually the first place people go
looking for information, and much of the information given there is
horribly outdated/wrong and mostly only concerns.


... concerns [D1].

Re: D on hackernews

[Andrei Alexandrescu]

On 9/21/11 8:52 AM, Timon Gehr wrote:

On 09/21/2011 09:37 AM, bearophile wrote:

Andrei Alexandrescu:


http://hackerne.ws/item?id=3014861

Apparently we're still having a PR issue.


I think the Wikipedia D page needs to be rewritten, leaving 80-90% of
its space to D (meaning D2).



Yes, that is important. Wikipedia is usually the first place people go
looking for information, and much of the information given there is
horribly outdated/wrong and mostly only concerns.


Agreed. Does anyone volunteer for fixing D's Wikipedia page?

Andrei

Re: D on hackernews

[Timon Gehr]

On 09/21/2011 06:38 AM, Nick Sabalausky wrote:

"Andrei Alexandrescu"  wrote in message
news:j5bpbf$1g2u$1...@digitalmars.com...

http://hackerne.ws/item?id=3014861

Apparently we're still having a PR issue. I tried to chime in but I can't
add a comment.



Looks like hackernews must be be having some sort of technical problem. I've
posted there before with no problem, and my "karma" is 12. But I'm logged in
now, and it's not giving me any way to reply either.




It seems like the thread has been closed. ("[dead]")

Re: D on hackernews

[Timon Gehr]

On 09/21/2011 09:37 AM, bearophile wrote:

Andrei Alexandrescu:


http://hackerne.ws/item?id=3014861

Apparently we're still having a PR issue.


I think the Wikipedia D page needs to be rewritten, leaving 80-90% of its space 
to D (meaning D2).



Yes, that is important. Wikipedia is usually the first place people go 
looking for information, and much of the information given there is 
horribly outdated/wrong and mostly only concerns. Many people think 
what's on Wikipedia is true. [citation needed]


"For performance reasons, string slicing and the length property operate 
on code units rather than code points (characters), which frequently 
confuses developers.[27]"


The link at [27] only says that many programmers that don't had have to 
handle unicode have trouble understanding how unicode works initially. 
It is not a D thing in any other way than that D actually supports 
unicode natively. Yet the 'D strings are strange and confusing' argument 
comes up quite often on the web, probably because many feel they are 
competent enough to discuss the language after having read the Wikipedia 
article.

Re: D on hackernews

[Andrej Mitrovic]

On 9/21/11, Andrei Alexandrescu  wrote:
> http://hackerne.ws/item?id=3014861
>
> Apparently we're still having a PR issue.

I really doubt this by now. We've mentioned a million times that
there's no dual standard libraries. I think this argument seems to be
re-introduced by trolls as far as I can tell.

Lazy binding of modules through templates

[Martin Nowak]

Have you ever done something like this?

struct AA(Key, Value)
{
import impl;
impl.AA!(Key, Value) _impl;
alias _impl this;
}

auto arrayOp(string exp, Oprnds...)(Oprnds oprnds)
{
import impl;
return impl.arrayOp!(exp, Oprnds)(oprnds);
}

I think this could be useful in simplifying the compiler to runtime  
interface.
Especially it could make associative arrays compile-time evaluatable  
without having

to put all source code into object.d.

martin