www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Things to look up in the docs

reply bearophile <bearophileHUGS lycos.com> writes:
In a language like C/D1 there are common simple parts that's easy to remember,
like:
int x = 10;

Other parts are more complex, but they are common enough that you usually
remember them:
for (int x = 10; x < foo.bar(); x += 2) {}

Other parts of the language or its standard library are less easy to remember,
but in normal programs they are uncommon enough that looking them into the docs
is acceptable. You don't need to keep in memory all the standard library of


But in a language (like D1/D2) there can be parts that are both common enough
and hard enough to remember, those are a problem, because looking in the docs
each time is a waste of programming time (especially if you don't have an IDE
under your hands) and more. Realistically it may be impossible to remove or
simplify all such parts from a large system language as D1/D2, but it's
important to write down a list of such parts, to keep such list in memory
during the language design, and to try to minimize the length of such list. In
theory some of the things in such list can be modified to make them more easy
to remember, etc.

It's nice to program in Python also because most common parts of the language
are easy to remember, for example the are't one undred string/list methods as
in Ruby, so after few months you memorize the most common Python string
methods, and this helps speed up programming significantly. 

What are the parts of the D1/D2 languages that are both common enough in
programs and not easy to remember, so you need to look them often in the docs
(or in an example list, code snippets list, already written code, etc)? This
list is partially subjective, but probably there are also some common trends.

For example the syntax of opApply is one of the things I have often to look up
in the docs (while I never need the manual to remember how to write a generator
in Python, that has very similar purposes).

Do you have other parts to add to this list?

Bye,
bearophile
Jan 01 2010
next sibling parent reply Don <nospam nospam.com> writes:
bearophile wrote:

 What are the parts of the D1/D2 languages that are both common enough in
programs and not easy to remember, so you need to look them often in the docs
(or in an example list, code snippets list, already written code, etc)? This
list is partially subjective, but probably there are also some common trends.
 
 For example the syntax of opApply is one of the things I have often to look up
in the docs (while I never need the manual to remember how to write a generator
in Python, that has very similar purposes).
 
 Do you have other parts to add to this list?
 
 Bye,
 bearophile


is() expressions.
Jan 01 2010
next sibling parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
On Fri, 01 Jan 2010 11:01:07 +0100, Don <nospam nospam.com> wrote:


 bearophile wrote:

 What are the parts of the D1/D2 languages that are both common enough  
 in programs and not easy to remember, so you need to look them often in  
 the docs (or in an example list, code snippets list, already written  
 code, etc)? This list is partially subjective, but probably there are  
 also some common trends.
  For example the syntax of opApply is one of the things I have often to  
 look up in the docs (while I never need the manual to remember how to  
 write a generator in Python, that has very similar purposes).
  Do you have other parts to add to this list?
  Bye,
 bearophile


 is() expressions.


Seconded. Often I end up using is( typeof( { something } ) ) because
it's faster than looking up and understanding how to write the
equivalent isExpression. Yet, I don't have much of an idea of how
to make it better. Is there a DIP for this?

-- 
Simen
Jan 01 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Simen kjaeraas:

 Seconded. Often I end up using is( typeof( { something } ) ) because
 it's faster than looking up and understanding how to write the
 equivalent isExpression. Yet, I don't have much of an idea of how
 to make it better. Is there a DIP for this?


I think is() has to be split in different things with a different (more
intuitive) syntax/naming.

Bye,
bearophile
Jan 01 2010
prev sibling parent retard <re tard.com.invalid> writes:
Fri, 01 Jan 2010 15:45:42 +0100, Simen kjaeraas wrote:


 On Fri, 01 Jan 2010 11:01:07 +0100, Don <nospam nospam.com> wrote:
 

 bearophile wrote:

 What are the parts of the D1/D2 languages that are both common enough
 in programs and not easy to remember, so you need to look them often
 in the docs (or in an example list, code snippets list, already
 written code, etc)? This list is partially subjective, but probably
 there are also some common trends.
  For example the syntax of opApply is one of the things I have often
  to
 look up in the docs (while I never need the manual to remember how to
 write a generator in Python, that has very similar purposes).
  Do you have other parts to add to this list? Bye,
 bearophile


 is() expressions.


 
 Seconded. Often I end up using is( typeof( { something } ) ) because
 it's faster than looking up and understanding how to write the
 equivalent isExpression. Yet, I don't have much of an idea of how to
 make it better. Is there a DIP for this?


It's funny how many of the original ideas in D (e.g. is()) feel so 
irrational and kludgy that at least I try to avoid them at all costs or 
at least build some wrappers around them.
Jan 04 2010
prev sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Don wrote:

 bearophile wrote:

 What are the parts of the D1/D2 languages that are both common enough 
 in programs and not easy to remember, so you need to look them often 
 in the docs (or in an example list, code snippets list, already 
 written code, etc)? This list is partially subjective, but probably 
 there are also some common trends.

 For example the syntax of opApply is one of the things I have often to 
 look up in the docs (while I never need the manual to remember how to 
 write a generator in Python, that has very similar purposes).

 Do you have other parts to add to this list?

 Bye,
 bearophile


 
 is() expressions.


...and template parameter specialisations, which are somewhat related 
since they use some of the same syntax.

   // Does T end up being the array or element type here?
   template Foo(T: T[]) { ... }

   // How many template parameters do I have to specify when
   // instantiating this template?
   template Bar(T: U*, U: int) { ... }

-Lars
Jan 01 2010
parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Fri, Jan 1, 2010 at 17:26, Lars T. Kyllingstad
<public kyllingen.nospamnet> wrote:


  // Does T end up being the array or element type here?
  template Foo(T: T[]) { ... }


Yeah, me too. So I end up putting external constraints and static ifs
everywhere:

template Foo(T) if isDynamicArray!T {
    alias ElementType!T E;
}


// How many template parameters do I have to specify when
// instantiating this template?
 template Bar(T: U*, U: int) { ... }


And is it the same than template Bar(U: int, T: U*) {...}?

Some others of the same kind:

why, to test if type U is a composite type (Cycle!(T), for example), do I
have to write
is(U u == Cycle!T, T)
and not
is(U == Cycle!T, T)? (If I'm not mistaken).
And to detect if some type is a std.typcons.tuple with
 is(T t = Tuple!U, U...)
doesn't work, because the is() doesn't accept variadic template arguments.
Too bad.
Jan 02 2010
prev sibling parent reply Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Fri, Jan 1, 2010 at 09:12, bearophile <bearophileHUGS lycos.com> wrote:



 What are the parts of the D1/D2 languages that are both common enough in
 programs and not easy to remember, so you need to look them often in the
 docs (or in an example list, code snippets list, already written code, etc)?
 This list is partially subjective, but probably there are also some common
 trends.


- variadic functions. I can't for the life of me remember if it's
foo(...)
foo(a...)
foo(a, ...)
and I always forget there is also foo(int[] a ...). Quick, what's the
difference with foo(int[] a) ?
And when I look at them in the docs, I'm, like "OMG, *void!".
So I end up writing foo(T...)(T args) and all is for the best: I got the
types, I got the length, I can static-if-act on them, I can put guards and I
can even recurse on them!

void foo(T...)(T args)
{
    writeln(args);
    static if (T.length)
        foo(args[1..$]);
}

- mixin. I have template Foo(T, U). In my code, should I write:
Foo!(int, double);
mixin Foo!(int, double);
mixin( Foo!(int, double));

When I discovered D some time ago, that was something that stalled me :(


Philippe
Jan 02 2010
parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Philippe Sigaud <philippe.sigaud gmail.com> wrote:


 - mixin. I have template Foo(T, U). In my code, should I write:
 Foo!(int, double);
 mixin Foo!(int, double);
 mixin( Foo!(int, double));


I feel there should be 'mixin templates', which require no

(http://d.puremagic.com/issues/show_bug.cgi?id=3666),

-- 
Simen
Jan 02 2010