Re: D2 is really that stable as it is claimed to be?

[Peter Williams]

On 25/09/13 06:29, Walter Bright wrote:

On 9/23/2013 11:38 AM, bearophile wrote:

2) The other improvement I'd like for D error messages and warnings is
to give a
standard error number. This is a simple improvement, but it makes
simpler to
write explanation pages for the errors. The C# compiler and other
compilers have
them.


I used to do that, but again, it was a completely unwanted feature, and
I abandoned it.

It's simple enough to grep for the error message text, and I myself
prefer to do the grep method.

What makes me grumpy is people only want these things when some other
compiler does it, sort of a bandwagon thing.


Grepping the text can be a problem if the output has been localised.

I write GUI wrappers for programs such as Mercurial/Git/Quilt and have 
been forced to use the (equivalent) of the grep to obtain details of the 
failure of a Mercurial/Git/Quilt command in order to add niceties as 
offering a "refresh and retry" option if (say) a quilt push fails 
because the repository needs to be refreshed.  The reason that I have to 
do this is that the error value returned by the commands isn't very 
useful (usually just 0 for success and -1 for failure).  The downside of 
this is that if my user has a locale that uses a language other than 
English my greps fail and the user misses out on the added niceties that 
would otherwise have been available.


The type of error return value I would have liked to have seen 
implemented in programs (I asked for changes but none were forthcoming) 
I write wrappers for would be a flag based system (I think that you can 
only count on 8 bits in the return value) to indicate the major 
characteristics of the failure.


Peter

Re: D2 is really that stable as it is claimed to be?

[Peter Williams]

On 23/09/13 07:12, Jonathan M Davis wrote:

On Sunday, September 22, 2013 16:50:05 Andrej Mitrovic wrote:

On 9/22/13, Jonathan M Davis  wrote:

Except that most of us don't care about the column number. It's of
marginal
benefit at best, and it harms compilation speed, so it's not worth it
IMHO.


You've never ran into lexer errors before have you?

test.d(10): Error: found ',' when expecting ')'

Now good luck finding where you forgot to put a closing brace in a
statement that uses traits or is(typeof( checks, such as this:

static assert(0, format("%s does not implement '%s'",
__traits(identifier, typeof(this))), __FUNCTION__);

It should have been:

static assert(0, format("%s does not implement '%s'",
__traits(identifier, typeof(this)), __FUNCTION__));

That's just a trivial case though.

I run into these all the time, and I have to spend half a minute
scanning left and right trying to figure out where the damn missing
brace went. Marginal benefit my ass.


Except that because the compiler doesn't know where the terminator should have
been, it can't give you a column number anyway. In that case, it can't even
give you the correct line number. At best, it can tell you the line number
where the unmatched symbol was, and that's often not helpful (especially with
braces). And even with parens, because the compiler doesn't know what you
actually meant to do, it's not like it can tell you where exactly in the
expression or statement you need to fix your code anyway. I really don't think
that a column number would help much here.


With my dunnart LALR(1) parser generator, the lexer that's generated as 
part of the generated parser passes its tokens as class instances that 
give access to the line number and column at which the token was found 
in the text and the exact slice of the input text that was matched to 
form the token.  That information travels with the token (rather than 
being something you have ask the lexer for in most lexers e.g. flex) so 
it's always available no matter where the token pops up in the parser.


Similarly, when the parser does a reduce, the non terminal grammar 
symbol acquires the positional data for the first token in the reduced 
sequence.


Peter

Re: [OT] Which IDE / Editor do you use?

[Peter Williams]

On 16/09/13 18:07, John Colvin wrote:


Ever since watching a friend have his entire /usr deleted by a dodgy
'sudo make install', i desperately avoid manually installing to anywhere
but a dedicated subdir in $home. No root access needed and I actually
know where everything is =)


In order for users of my PyGTK scripts to not have to risk the integrity 
of their system (by installing them from my source rather than through 
their package manager), I go out of my way to make sure that all that is 
required is for the source directory to be in their $PATH (or 
alternatively run them with the full path to the executable) in order 
for them to be usable.  Because Python scripts know the directory where 
they're installed (as well as where they're run from) it's possible to 
know where to look for any support files using this data and Python 
automatically includes the installed directory and its subdirectory when 
it looks for library packages/modules.


This saves me the bother of having to learn how to make packages for all 
the different systems out there without asking the user to compromise 
their system integrity.


Peter
PS I also provide an install script so the users have that option and 
the location of the root directory for the installation is configurable.

Re: [OT] Which IDE / Editor do you use?

[Peter Williams]

On 16/09/13 11:47, H. S. Teoh wrote:

On Sun, Sep 15, 2013 at 07:32:48PM +0200, Adam D. Ruppe wrote:

On Sunday, 15 September 2013 at 16:50:50 UTC, Dicebot wrote:

After I have switched to Gnome Shell I can't use any other desktop
manager comfortably.


This is actually feel about my custom setup based on the Blackbox
window manager. It has a lot of little differences from the other
common options:

1) sloppy focus. omg it is so much better than click to focus


Back when I was still using a GUI, sloppy focus was one of the only
things that made it tolerable to use.


I kind of agree but I use "focus follows mouse" rather than sloppy.  I 
could never understand why most windows managers make "click to change 
focus" the default as clicking inevitably raises the newly focussed 
window to the top as well as changing the focus.  This greatly reduces 
flexibility when managing overlapping windows.


Peter
PS One of the reasons that I dumped Gnome 3 for Cinnamon is that the 
Gnome people seem determined to remove all user configuration options 
(in the pursuit of an homogenous desktop) and I figured that it was only 
a matter of time before they removed the ability to choose what type of 
focus control one wanted.  They'd already removed the ability to 
configure some things that I always changed from the default.

Re: [OT] Which IDE / Editor do you use?

[Peter Williams]

On 14/09/13 14:52, Walter Bright wrote:

On 9/13/2013 8:48 PM, Andrei Alexandrescu wrote:

On 9/13/13 4:43 PM, Iain Buclaw wrote:

On 14 September 2013 00:39, Piotr Szturmaj  wrote:

On 13.09.2013 21:48, Namespace wrote:


Just out of interest.

I use Sublime 2, Notepad++ and as IDE currently Mono-D. But I will try
this evening VisualD.



Real Programmers magnetize programs directly on a HDD.


Excuse me, but /real/ programmers use Butterflies.


For the few souls who don't yet... http://xkcd.com/378/


I've used punch cards and paper tape. But I refused to use paddle switches.


Programming with paddle switches on a PDP-8 wasn't that hard.  Not much 
different to using a programmable calculator and the available 
instruction set was small, logically (not randomly) designed and easy to 
remember.


Peter

Re: [OT] Which IDE / Editor do you use?

[Peter Williams]

Geany mainly on Linux but also on Windows (but not much as I only fix 
Windows specific issues in my code on Windows and do most of my work on 
Linux).  I use my own PyGTK GUI wrapper for git for source management.


Peter

Re: dub: should we make it the de jure package manager for D?

[Peter Williams]

On 11/09/13 06:48, Andrei Alexandrescu wrote:

We've been experimenting with http://code.dlang.org for a while and
things are going well. In particular Sönke has been very active about
maintaining and improving it, which brings further confidence in the
future of the project.

We're considering making dub the official package manager for D. What do
you all think?


Is there a 64 bit rpm for dub?

Peter

Re: Move VisualD to github/d-programming-language ?

[Peter Williams]

On 09/09/13 15:55, Jonathan M Davis wrote:

On Monday, September 09, 2013 07:41:44 Volcz wrote:

Good idea!

What about other useful projects? I know that a official lexer
was discussed some time ago. What about DCD? Should ex VisualD
use software like DCD if both are on the dlang GitHub?


The plan is to integrate a full lexer and parser into Phobos (and hopefully
eventually have dmd use those sometime after the front-end has been converted
to D). So, I wouldn't expect there to be any separate projects for those to be
moved into github/d-programming-language.

I also don't think that we should rush and try and shove a bunch of projects
in the official D github org. If it makes sense to put something there, then we
should put something there, but IMHO it needs to actually have a good reason
to be official, not just because it's useful.

- Jonathan M Davis



I'll take this opportunity to remind people of dunnart (on github under 
user name pwil3058) which is an enhanced LALR(1) parser generator for D. 
 Lexical analysis specification is a part of the overall grammar 
specification (using std.regex type regular expressions).  The lexical 
analysis part of this code can also be used separately if desired (but 
only on strings and not on streams i.e. read the whole file into a 
string and give it to the lexer rather than giving the lexer the file 
and letting it pull characters in one at a time).


Unfortunately, like most software, the documentation is still a bit less 
than ideal/complete but I'll gladly answer questions if anyone wants to 
use it.


Peter

Re: D and Emacs [ was Re: Move VisualD to github/d-programming-language ? ]

[Peter Williams]

On 10/09/13 04:32, Kapps wrote:

On Monday, 9 September 2013 at 18:03:20 UTC, Paulo Pinto wrote


On Windows world, Mercurial still has the edge over Git, given the
poor Windows support.

This will eventually change given the recent endorsement Microsoft has
given to Git on their tooling, but it will still take some time to
change.

--
Paulo


I find Git on Windows to be very nice actually. I just download
GitExtensions, which installs Git and KDiff and such, as well as an
awesome extension for Visual Studio. That extension is the best version
control IDE integration I've ever used. Git Extensions will also set git
up for command prompt, and optionally include tools like ssh-keygen so
you can use the command line as you would on Linux. Perhaps there was a
time that Windows support for Git was terrible, but I find it excellent
now.


For those who prefer Mercurial to Git (I used to be one but I've since 
gone with the tide) there is a Mercurial extension 
 which enables you to clone a 
git repository with Mercurial and then do pushes, pulls etc with that 
repository as if it were a Mercurial one.  This means that you can use 
github without having to learn git.


Peter

Re: new DIP47: Outlining member functions of aggregates

[Peter Williams]

On 08/09/13 16:47, Walter Bright wrote:

On 9/7/2013 11:08 PM, Peter Williams wrote:

In summary, you've gotten rid of the need for this type of duplication
so why
would you introduce it?


I believe that is covered in the "Rationale" section of the dip.


Couldn't see a rational answer to my question in the rationale.

Looked more like a "I want to do this and I think that we should change 
the language syntax to allow it" statement to me.  It doesn't really add 
functionality just makes what's there more complex.


Peter

Re: new DIP47: Outlining member functions of aggregates

[Peter Williams]

On 08/09/13 22:46, Gary Willoughby wrote:

On Saturday, 7 September 2013 at 17:00:08 UTC, Walter Bright wrote:

Outlining of member functions is the practice of placing the
declaration of a member function in the struct/class/union, and
placing the definition of it at global scope in the module or even in
another module.

http://wiki.dlang.org/DIP47


I'm absolutely against this DIP.

This proposal is just going back to the hell of header files again. Why
on earth would you emulate C/C++ when D was supposed to be designed
taking into account lessons learned from them. This is unnecessary
complexity added for the sake of a few programmers who can't get out of
C++ mode. I think you need to have a good hard think about *why* header
files were introduced into those early languages and then consider if
that reason is still valid. Personally i don't think it is. Java and C#
do just fine without this.

Seriously, this goes against everything you learn as a programmer,
nothing should ever be typed twice and then to say that the declaration
and implementation could be different just boggles my mind?!?! Great
more work!

If implemented, i will never used this feature and i will never deal
with code that uses it either. I choose D *purely* because it didn't
have this header file nonsense. If i find in future i start seeing more
and more of this style of D code i would just move on to use something
else that doesn't have all this extra baggage and work associated with
it. Just because Manu brings it up randomly you decide to create a DIP?

In reality this is a documentation issue. Which has already been
addressed by DDOC or *.di files. If data exists in one form, and it is
needed in another, that's work a computer should do. Not a human! IDE's
also give you numerous tools to get class overviews and such. If you are
suggesting that you also need these class overviews in code to be viewed
on github etc, just use comments. They are as arbitrary and simpler to
implement.

Honestly this DIP is going backwards, i was under the impression D was
going forwards! I am so disappointed.


Well said.

Peter

Re: new DIP47: Outlining member functions of aggregates

[Peter Williams]

On 08/09/13 15:40, Walter Bright wrote:

On 9/7/2013 9:46 PM, Jonathan M Davis wrote:

On an implementation note, I don't think that #5 is strong enough. I
think
that it should be an outright error if there is a difference between the
declaration and definition rather than giving one precedence over the
other.


I'll point out that C++ has equivalent behavior, and it has not resulted
in any complaints I've ever heard. When you outline a C++ member
function, you do not need to add 'static', 'private', 'virtual', and in
fact you cannot add the latter two.


Here's one. It's one of the things that I don't like about C/C++ as it 
doubles the work required in code maintenance.  One of the things that I 
like about D is that forward references aren't required and this seems 
to me to be introducing a feature that was only ever in C/C++ to make 
forward references possible (which is why I tolerated it).


In summary, you've gotten rid of the need for this type of duplication 
so why would you introduce it?


Peter

Re: obsolete D libraries/modules

[Peter Williams]

On 06/09/13 14:18, Peter Williams wrote:

On 29/08/13 16:34, Peter Williams wrote:

On this topic, I started looking at porting one of my PyGTK applications
to GtkD and found that the knowledge of PyGTK API wasn't a great deal of
help in this endeavor.  I think the problem is Python's "duck typing"
and dynamic typing allow for a very flexible API that is much simpler
than GTK+'s and GtkD's is much like GTK+'s.  The problem is complicated
by the fact that the amount of documentation is huge and it's often
difficult to find where something is defined.

Anyway, long story short, I've decided to investigate the feasibility of
rewriting the parts of GTK+ that I like directly in D.  It's early days
yet and the code is in a private repository on github.  I'll keep it
private until I have some useful subset working at which time I'll make
it public.  Of course, if I find that it's all too hard I'll just delete
it.

Early indications are that the code will be much simpler than the
original as GTK+ implements its own OOP and GC where I'll just delegate
that to D. :-)


Reality check :-) - this is a huge job.  So I've amended my goals a
little.  New plan is to start with just replacing the gtk+/gtk component
and use wrappers to gdk, pango etc.  I did think about chucking it in
altogether and using GtkD but the API in there hints that the onus of
managing memory is placed on the user and that just makes writing a GUI
that much harder.

I'm hoping that my wrappers can be implemented in such a way that memory
management is hidden inside them.


One thing that's obvious with my progress so far is that a huge amount 
of the code in GTK+ is there to implement coding features/conveniences 
that come for free with D (with much simpler APIs).  I reckon that if D 
had been around to implement the original GTK+ the source would be an 
order of magnitude smaller and a lot easier to understand.


Peter

Re: obsolete D libraries/modules

[Peter Williams]

On 29/08/13 16:34, Peter Williams wrote:

On 29/08/13 16:11, Rikki Cattermole wrote:

I will say this, one thing about D that has annoyed me from the
beginning is the state of the gui libs. Hence why in last month I've
been having a real good play around with OpengGL and creating my own
library [1].


On this topic, I started looking at porting one of my PyGTK applications
to GtkD and found that the knowledge of PyGTK API wasn't a great deal of
help in this endeavor.  I think the problem is Python's "duck typing"
and dynamic typing allow for a very flexible API that is much simpler
than GTK+'s and GtkD's is much like GTK+'s.  The problem is complicated
by the fact that the amount of documentation is huge and it's often
difficult to find where something is defined.

Anyway, long story short, I've decided to investigate the feasibility of
rewriting the parts of GTK+ that I like directly in D.  It's early days
yet and the code is in a private repository on github.  I'll keep it
private until I have some useful subset working at which time I'll make
it public.  Of course, if I find that it's all too hard I'll just delete
it.

Early indications are that the code will be much simpler than the
original as GTK+ implements its own OOP and GC where I'll just delegate
that to D. :-)


Reality check :-) - this is a huge job.  So I've amended my goals a 
little.  New plan is to start with just replacing the gtk+/gtk component 
and use wrappers to gdk, pango etc.  I did think about chucking it in 
altogether and using GtkD but the API in there hints that the onus of 
managing memory is placed on the user and that just makes writing a GUI 
that much harder.


I'm hoping that my wrappers can be implemented in such a way that memory 
management is hidden inside them.


Peter

Re: Replacing std.xml

[Peter Williams]

On 03/09/13 12:40, Lionello Lunesu wrote:

On 8/29/13 15:25, w0rp wrote:

Hello everybody. I've been wondering, what are the current plans to
replace std.xml? I'd like to help with the effort to get a final XML
library in phobos. So, I have a few questions.

First, and most importantly, what do we except out of a D XML library?
I'd really like to have a discussion of the form, "Here is exactly the
interface the structs/classes need to implement, go forth and
implement." The general idea in my mind is "something SAX-like, with
something a little DOM-like." I'm aware that std.xml has some issues
support different encodings, so obvious that's included.

Second, is there an existing library that has gotten close to meeting
whatever we need for the first point? If so, how far away is it from
being able to meet all of the requirements and become the standard
library version?


Having been the lead programmer on the Microsoft XML team for three
years, I can easily say that the most popular XML API [on MS stack] is
the XmlReader and XLinq in .NET. (This has nothing to do with LINQ, by
the way.)

I'd be willing to help make D versions of that, but my time is limited.
But as usual, I don't think it's the actual coding that will take time.
Designing a good interface is the hardest part, and I'd consider that
part done.

L.


For whoever ends up doing std.xml's replacement, it would be good if 
some of the lower level interfaces such as encode/decode (for 
escaping/unescaping within text) were exposed.  I'm finding the ones in 
std.xml useful for implementing markup in label widgets during my 
investigation into reimplementing the GTK+ (modified) interface in D.


Of course, there's always the chance that the new D xml API provides 
enough to make my markup code redundant.  It's possible that the current 
high level APIs in std.xml also provides enough make my work redundant 
but I decided not to investigate this possibility after I saw the "will 
be replaced by something different" warning.


Cheers
Peter

Re: End user experience with D

[Peter Williams]

On 02/09/13 14:24, H. S. Teoh wrote:

On Mon, Sep 02, 2013 at 12:21:08AM +0200, Ramon wrote:
[...]

D's bias toward Windows doesn't help either.

[...]

I'm confused by this statement.


I think this may be a reference to parts of Phobos which are a bit 
Windowsish with Posix tacked on rather than Posix with special cases for 
Windows' lack of support for some features.

Re: End user experience with D

[Peter Williams]

On 02/09/13 14:12, Ramon wrote:

On Monday, 2 September 2013 at 04:00:37 UTC, Peter Williams wrote:


IMHO, the IDE should only be a wrapper around the core functionality
and never be so closely integrated that the core is unusable without
the IDE.  Personally, I just like using a configurable editor (e.g.
Geany, emacs and so on) which knows (or can be taught) how to do
various useful things that an IDE might offer.

If you want an IDE then create one but make it an "add on" and don't
expect everyone to use it.

Cheers
Peter
PS I especially hate IDEs that try to force me to create "projects".
PPS I especially like IDEs that have built in terminal editors so that
you can do command line stuff without the need for a separate window.


I perfectly agree. An IDE should be optional - but it should
exist.


OK, but why are you putting the onus on Walter to create it.  He's 
looking after the core technology and probably has enough to do already. 
 Surely someone (such as you) who wants an IDE should be the person to 
create it.




And btw: With IDE I don't necessarily mean a fully blown Eclipse
like thing. A smart developer oriented editor (like Geany) with a
reasonable interface to a *working* debugger is good enough.


I agree there.  I tried to use Eclipse way back when it first came out 
and it was already to complicated (and too Java centric) for my taste. 
If I recall correctly it was also one of those that insisted on 
"projects" and all source files in its own directory tree.


Peter
PS I too like GUIs for doing some things and if there isn't one 
available (that suits my way of working) I knock one up myself using a 
PyGTK wrapper around the command line interface (e.g. gquilt and gwsmhg 
for quilt and Mercurial respectively) and when it's working I make it 
public just in case it scratches someone else's itch.

Re: End user experience with D

[Peter Williams]

On 02/09/13 09:36, Ramon wrote:

On Sunday, 1 September 2013 at 23:22:30 UTC, Adam D. Ruppe wrote:

On Sunday, 1 September 2013 at 22:21:10 UTC, Ramon wrote:

Finally and possibly most importantly, basically not having fully
working  debugger support is a very serious lack.


Maybe it is because I write 100% bug free code the first time every
time ( :-) ) but I've found the gdb support, at least on Linux, to be
really pretty good.

I compile with -gc -debug - the "pretend to be C" option is something
I started doing years ago and might not be necessary anymore, but I've
found it to be plenty good enough anyway.


D's bias toward Windows doesn't help either.


If anything, I don't think D goes far enough in its Windows support.
It works well there, sure, even the optlink things others complain
about don't bother me, but there's a lot of stuff it could easily do
and doesn't, at least not without grabbing additional downloads.

On Linux, dmd works quite excellently, as do gdc and ldc.


-gc? Hmmm ... I'll try that. Thanks for the tip ;)

For the rest: Frankly, I'm not even sure, I should follow that kind of
discussion (like in Manu's thread) anymore. I don't mean to offend
someone but it strikes me as ... uhm ... brains not used at their full
power ... when "there is no really properly and fully working IDE"
(which is pretty close to a killer for many) gt thrown in - and
seriously - discussed with stuff like "nenene, in Windows Visual Blah
2010 it worked and now Intellisense works only with handish settings,
nenene".
Even worse, while I'm still hoping for a promising statement by a
heavy-weight like e.g. W. Bright along the line "Yep, we really,
seriously need some working cross platform IDE, preferably an easy to
install one" ... one seems quite happy to seriously adress nitty-bitties
for Windows Whatever 2012 (c) (tm) $$$.

Maybe perfection must be three, the catholic way, a triplet. Maybe we
need another incarnation of Andrei A. (who brought great stuff to D) but
this third guy bringing good useabilty to D.


IMHO, the IDE should only be a wrapper around the core functionality and 
never be so closely integrated that the core is unusable without the 
IDE.  Personally, I just like using a configurable editor (e.g.  Geany, 
emacs and so on) which knows (or can be taught) how to do various useful 
things that an IDE might offer.


If you want an IDE then create one but make it an "add on" and don't 
expect everyone to use it.


Cheers
Peter
PS I especially hate IDEs that try to force me to create "projects".
PPS I especially like IDEs that have built in terminal editors so that 
you can do command line stuff without the need for a separate window.

Re: obsolete D libraries/modules

[Peter Williams]

On 01/09/13 12:29, Jonathan M Davis wrote:

On Saturday, August 31, 2013 19:18:11 Andrei Alexandrescu wrote:

I remember sitting next to Kirk McDonald at the D conference in 2007 as
he was showing me Python's argparse. I personally found pretty much any
example we could think of more verbose and uglier than std.getopt.


std.getopt is definitely lacking some nice-to-have features (like automatically
generating --help from the options), but for the most part,


That's the part of argparse that I miss the most.

Also, its support for sub commands is excellent.  I implemented a 
version of quilt in Python and argparse made adding sub commands a 
breeze once the main engine was complete.


I must admit that I toyed with the idea of implementing argparse in D 
myself but rejected the idea when I realised that hard typing in D would 
make it a non trivial exercise.


But I still think the basic ideas (i.e. integrated documentation, 
specifying how many no option arguments there can be and support for sub 
commands) are good.  I especially like the integrated documentation as 
it makes code maintenance much easier when everything about an 
option/argument is in the one place.


Peter
PS before argparse I used to use getopt (C and Python) and I still 
haven't decided whether I like D's version better than the originals 
(probably yes for C and no for Python).

Re: obsolete D libraries/modules

[Peter Williams]

On 01/09/13 03:11, Andrei Alexandrescu wrote:

Haven't seen Tango's arguments parser, but it's a given getopt can be
improved in any number of ways. Yet the way I see it, with command line
parsing, the margin between a good enough argument parser and a terrific
one is razor thin. One parses arguments by definition once in every
program, and things like checking against limits and constraints across
multiple arguments can be easily done after basic parsing.



The Python Standard Library's argparse module 
 would be a good model 
to base an improved option parsing module on.  I've used it a lot in 
Python and it's very useful.


Peter

Re: obsolete D libraries/modules

[Peter Williams]

On 29/08/13 19:23, Paul Jurczak wrote:

On Thursday, 29 August 2013 at 06:34:23 UTC, Peter Williams wrote:

On 29/08/13 16:11, Rikki Cattermole wrote:

I will say this, one thing about D that has annoyed me from the
beginning is the state of the gui libs. Hence why in last month I've
been having a real good play around with OpengGL and creating my own
library [1].


On this topic, I started looking at porting one of my PyGTK
applications to GtkD and found that the knowledge of PyGTK API wasn't
a great deal of help in this endeavor.  I think the problem is
Python's "duck typing" and dynamic typing allow for a very flexible
API that is much simpler than GTK+'s and GtkD's is much like GTK+'s.
The problem is complicated by the fact that the amount of
documentation is huge and it's often difficult to find where something
is defined.

Anyway, long story short, I've decided to investigate the feasibility
of rewriting the parts of GTK+ that I like directly in D.  It's early
days yet and the code is in a private repository on github.  I'll keep
it private until I have some useful subset working at which time I'll
make it public.  Of course, if I find that it's all too hard I'll just
delete it.

Early indications are that the code will be much simpler than the
original as GTK+ implements its own OOP and GC where I'll just
delegate that to D. :-)

Peter


In case you didn't know, there is a C++ wrapper for GTK+ called gtkmm
(http://www.gtkmm.org/en/). It may be useful as an example of object
oriented interface to GTK+.


Thanks, but GTK+ IS an object oriented interface (just written C) so 
looking at the C++ interface would just mean more work for me with 
little gain.

Re: obsolete D libraries/modules

[Peter Williams]

On 29/08/13 16:44, Rikki Cattermole wrote:

On Thursday, 29 August 2013 at 06:34:23 UTC, Peter Williams wrote:

On 29/08/13 16:11, Rikki Cattermole wrote:

I will say this, one thing about D that has annoyed me from the
beginning is the state of the gui libs. Hence why in last month I've
been having a real good play around with OpengGL and creating my own
library [1].


On this topic, I started looking at porting one of my PyGTK
applications to GtkD and found that the knowledge of PyGTK API wasn't
a great deal of help in this endeavor.  I think the problem is
Python's "duck typing" and dynamic typing allow for a very flexible
API that is much simpler than GTK+'s and GtkD's is much like GTK+'s.
The problem is complicated by the fact that the amount of
documentation is huge and it's often difficult to find where something
is defined.

Anyway, long story short, I've decided to investigate the feasibility
of rewriting the parts of GTK+ that I like directly in D.  It's early
days yet and the code is in a private repository on github.  I'll keep
it private until I have some useful subset working at which time I'll
make it public.  Of course, if I find that it's all too hard I'll just
delete it.

Early indications are that the code will be much simpler than the
original as GTK+ implements its own OOP and GC where I'll just
delegate that to D. :-)

Peter


Nice :)
Although be careful it was designed for more Posix environment.
I'm keeping DOOGLE as far limited in terms of platform dependence.
So porting is literally implement the OpenGL context creation and Window
creation classes.

Also for anyone interested I'm keeping the controls that require text
out of DOOGLE because of the font rasterizer dependency.


I'm starting at the top and working towards the "down and dirty" bits so 
issues such as platform dependence haven't arisen yet.  My strategy is 
to look at the header file for a widget and extract its public interface 
and then implement a D class with that interface using the widget's C 
source file for guidance.


My thinking is that when I get to the bottom I define an abstract 
interface for the "down and dirty" part and then implement it for the 
back end of my choice leaving others to do the same for the back end of 
their if they can't wait for me to get around to it. Design of this 
interface is probably something I will need assistance from people 
familiar with Windows/Mac/X11/Weyland so that the interface is 
implementable and not biased towards one or another.

Re: obsolete D libraries/modules

[Peter Williams]

On 29/08/13 16:11, Rikki Cattermole wrote:

I will say this, one thing about D that has annoyed me from the
beginning is the state of the gui libs. Hence why in last month I've
been having a real good play around with OpengGL and creating my own
library [1].


On this topic, I started looking at porting one of my PyGTK applications 
to GtkD and found that the knowledge of PyGTK API wasn't a great deal of 
help in this endeavor.  I think the problem is Python's "duck typing" 
and dynamic typing allow for a very flexible API that is much simpler 
than GTK+'s and GtkD's is much like GTK+'s.  The problem is complicated 
by the fact that the amount of documentation is huge and it's often 
difficult to find where something is defined.


Anyway, long story short, I've decided to investigate the feasibility of 
rewriting the parts of GTK+ that I like directly in D.  It's early days 
yet and the code is in a private repository on github.  I'll keep it 
private until I have some useful subset working at which time I'll make 
it public.  Of course, if I find that it's all too hard I'll just delete it.


Early indications are that the code will be much simpler than the 
original as GTK+ implements its own OOP and GC where I'll just delegate 
that to D. :-)


Peter

Re: Invariants are useless the way they are defined

[Peter Williams]

On 25/08/13 22:16, deadalnix wrote:

As they are defined now, invariant are plain useless. I find myself
disabling them one by one in my code as soon as cases get outside simple
trivia.

The problem is that invariant are checked at the beginning/end on public
function calls. As a consequence, it is impossible to use any public
method in an invariant.

For instance, just right now I did refactor a struct to use bitfields,
in order to make it more compact. Now I have to remove the invariant as
field access are now function calls.

Another typical situation is when you want to assert certain properties
in a class hierarchy, where calling virtual method is part of the
invariant check.

invariant should (and must to be useful) be inserted at callee point,
when the callee isn't itself subject to invariant insertion, and around
public memeber manipulation (when the manipulator isn't subject to
invariant insertion).

Any other pattern it doomed to create infinite recursion for non trivial
invariant checks.


I just discovered another (surprising to me) shortcoming with the 
implementation of invariants: namely they don't get checked during the 
default initiation of a struct.  By default, I mean the initialization 
process that you get when you don't provide a this() method.


This probably doesn't matter in the grand scheme of things as I imagine 
an instance of the struct that breaks the invariant cant be used without 
triggering a check.  However, for me, it meant I had to use two 
statements in my unit tests (instead of one) to test the invariant. 
Also, the deferred triggering of the invariant could make debugging more 
difficult.


Peter

Re: Why I chose D over Ada and Eiffel

[Peter Williams]

On 20/08/13 06:18, Ramon wrote:

Falling over the famous Ariane 5 article I looked at Eiffel. I have to
confess that I almost feel in love. Eiffel felt just right and Prof.
Meyers books convinced me again and again - Yesss, that's the way I'd
like to work and develop software.
Unfortunately, though, Prof Meyer and ISE (the Eiffel company) made some
errors, too, and in a major way.
For a starter that whole Eiffel world is pretty much a large beautiful
castle ... inmidst a desert. Theoretically there are different
compilers, factually, however, ISE's Eiffelstudio is the only one; the
others are either brutally outdated or non-conforming or weird niche
thingies or eternally in alpha, or a mixture of those. And Eiffelstudio
costs north of 5.000 us$. Sure there is a GPL version but that is
available only for GPL'ed programs.
Next issue: Eiffels documentation is plain lousy. Yes, there are some 5
or so books but those are either purely theoretical or very outdated or
both. Yes there is lots of documentation online but most of it basically
is luring sales driven "Look how easy it is with Eiffel" stuff. And
there is a doxygen like API doc which is pretty worthless for learning
how to practically use the language.
Furthermore, while Eiffel comes with a lot on board there still is much
missing; just as an example there are no SSL sockets which nowadays is a
killer.


I found similar issues with Eiffel plus I was turned off by the OOP only 
factor.  Programming needs to be more flexible than that.


BTW using Eiffel was where I first realized that contracts would never 
be as useful as I hoped.  They're still useful and I still use them but 
they're not as expressive as I'd hoped for (neither are D's).  In 
reality, they're just highly targeted unit tests.  I think my 
disappointment stems from the fact I used to write Z specifications and 
I would liked to have contracts that were the equivalent.


Peter

Re: Designing a consistent language is *very* hard

[Peter Williams]

On 15/08/13 20:51, Joakim wrote:

On Thursday, 15 August 2013 at 01:59:49 UTC, deadalnix wrote:

On Thursday, 15 August 2013 at 01:56:09 UTC, Tyler Jameson Little wrote:

On Wednesday, 14 August 2013 at 12:09:27 UTC, Dejan Lekic wrote:

Speaking about PHP... I believe we all read that article. I could
say worse about ASP than what that article says about PHP.


That doesn't mean that ASP is worse than PHP though. PHP is so bad
that I've actually considered offering up my time pro-bono to rewrite
sites written in PHP to pretty much anything else.

The only thing that excites me more than seeing PHP die is seeing
IE6/7/8 die, and that's already happening. =D


That would change much, we would still have Objective C and JS. And
you know that everything MUST be done in JS !


Heh, at my job last year, one guy was duplicating significant business
logic in javascript in the browser, that was already on the server, so
that GUI lag was lessened.  This blew my mind as I thought it should
have been done in AJAX, so that business logic stayed on the server, as
keeping the logic synced would probably get hairy, even though AJAX is
not going to be _as_ fast as local javascript.  But there were lots of
other problems at that job, and he was so far from the worst of it, that
I just looked at him like he was crazy and moved on. :)

You mention Obj-C: how bad is it?  I don't frequent Apple sites and
nobody really talks about it in my orbit.  I figure it must be pretty
bad since it was designed decades ago and hasn't been updated much, but
I'd like to hear what exactly it gets wrong.


It's pretty ugly.  But at least it's not C++.

Peter

Re: Are we getting better at designing programming languages?

[Peter Williams]

On 24/07/13 04:02, Tofu Ninja wrote:

On Tuesday, 23 July 2013 at 16:24:15 UTC, Jonathan A Dunlap wrote:

Check it out: D is listed rather favorably on the chart..
http://redmonk.com/dberkholz/2013/07/23/are-we-getting-better-at-designing-programming-languages/



 From my understanding of the article, lower on the graph means more
'expressive' and higher means less 'expressive'? Correct me if i am wrong.


You're right. And the consequence is that D didn't do very well at all 
on the chart.  Whether the metric used to measure "expressiveness" is 
valid is another question?  My personal view would be that it's a highly 
dubious metric.


Peter

Re: Notes from C++ static analysis

[Peter Williams]

On 28/06/13 11:47, Jonathan M Davis wrote:

On Friday, June 28, 2013 10:44:36 Peter Williams wrote:

On 28/06/13 05:52, Jonathan M Davis wrote:

On Thursday, June 27, 2013 13:47:53 Adam D. Ruppe wrote:

On Thursday, 27 June 2013 at 06:59:49 UTC, Jonathan M Davis wrote:

But if we make a design decision that favors 1% of our userbase


I really think we all need to be more careful about these kinds
of statements. I often see posts on the newsgroup where someone
says "feature/function X is totally useless" and it is
something I actually use.

In this thread, there's I think three people who said the extra
arguments are a good thing (myself, Andrei, and Peter). And
there's what, maybe a dozen participants in the thread (I didn't
count, I think it is less though)?

That's not a big enough sample to be statistically significant,
but what are the odds that this thread is so skewed that only 1%
of D's userbase feels this way, when 25% of the thread disagrees?


I wasn't arguing that only 1% of the users care about this particular
feature. What I was objecting to was that Andrei seemed to think that
argumentum ad populum was an invalid argument,


Plato would agree with Andrei.


It's definitely true that just because a lot of people think something does not
make it true (e.g. having the majority of people think that the sun goes
around the earth does not make it so). But when you're debating an API, your
debating what a lot of people are going to be using, and if the majority of
them don't think that it's user-friendly or otherwise well-designed, then I
really don't think that it makes sense to say that the fact that most of the
users think that doesn't mean anything or that it's not relevant. I think that
majority opinion is _very_ relevant when discussing APIs or any type of user
interface. It may be the case that they're wrong and that after using a new
API or user interface, they'll eventually come to the conclusion that they're
wrong, but their opinion is _very_ relevant IMHO.


Yes, but voting is very seldom the best way so decide a technical issue. 
 You want the best technical solution not the one supported by the best 
lobbyists.


Peter

Re: Notes from C++ static analysis

[Peter Williams]

On 28/06/13 05:52, Jonathan M Davis wrote:

On Thursday, June 27, 2013 13:47:53 Adam D. Ruppe wrote:

On Thursday, 27 June 2013 at 06:59:49 UTC, Jonathan M Davis wrote:

But if we make a design decision that favors 1% of our userbase


I really think we all need to be more careful about these kinds
of statements. I often see posts on the newsgroup where someone
says "feature/function X is totally useless" and it is
something I actually use.

In this thread, there's I think three people who said the extra
arguments are a good thing (myself, Andrei, and Peter). And
there's what, maybe a dozen participants in the thread (I didn't
count, I think it is less though)?

That's not a big enough sample to be statistically significant,
but what are the odds that this thread is so skewed that only 1%
of D's userbase feels this way, when 25% of the thread disagrees?


I wasn't arguing that only 1% of the users care about this particular feature.
What I was objecting to was that Andrei seemed to think that argumentum ad
populum was an invalid argument,


Plato would agree with Andrei.

Peter

Re: Notes from C++ static analysis

[Peter Williams]

On 27/06/13 23:33, bearophile wrote:

Andrej Mitrovic:


Yeah but it's not always possible to know what the formatting string
is. For example, maybe you have an enum array of format strings but a
runtime index into this array which you pass to format at runtime.
I've ported C samples before that used this style of formatting.


In some cases the format string is computed at run-time, so it can't be
a template argument. A ctWritefln is for the other cases.


In internationalized/localized code the string is highly likely to be 
determined at run time.


Peter

Re: Notes from C++ static analysis

[Peter Williams]

On 27/06/13 14:20, H. S. Teoh wrote:

On Thu, Jun 27, 2013 at 01:56:31PM +1000, Peter Williams wrote:
[...]

While you're fixing it can you modify it so that the format string
can specify the order in which the arguments are replaced?  This is
very important for i18n.  I apologize if it can already do this but
I was unable to find any documentation of format()'s format string
other than examples with %s at the appropriate places.

[...]

You can use positional arguments for this purpose. For example:

writefln("%2$s %1$s", "a", "b");

outputs "b a".


Yes, I eventually found the documentation in std.format while I expected 
it to be in std.string along with the documentation the format() 
function.  A reference to std.format in the documentation for format() 
(in std.string) would be nice.


Peter

Re: Notes from C++ static analysis

[Peter Williams]

On 27/06/13 12:17, Andrei Alexandrescu wrote:

On 6/26/13 1:31 PM, Andrej Mitrovic wrote:

On 6/26/13, Andrei Alexandrescu  wrote:

Actually this is good because it allows to customize the format string
to print only a subset of available information (I've actually used
this).


Note that this works:

writefln("%d", x, x);

But the following throws since v2.061:

writeln(format("%d", x, x));

std.format.FormatException@C:\dmd-git\dmd2\windows\bin\..\..\src\phobos\std\string.d(2346):

Orphan format arguments: args[1..2]

I find the latter to be quite useful for debugging code, and wanted
this feature for a long time.


I think that's a bug in format that we need to fix.


While you're fixing it can you modify it so that the format string can 
specify the order in which the arguments are replaced?  This is very 
important for i18n.  I apologize if it can already do this but I was 
unable to find any documentation of format()'s format string other than 
examples with %s at the appropriate places.


Peter

Re: Notes from C++ static analysis

[Peter Williams]

On 27/06/13 10:33, Walter Bright wrote:

On 6/26/2013 4:48 PM, Timon Gehr wrote:

On 06/27/2013 01:01 AM, Walter Bright wrote:

On 6/26/2013 3:56 PM, Walter Bright wrote:

On 6/26/2013 2:47 PM, Paulo Pinto wrote:

I have been an adept of iostreams since day one and never understood
why people
complain so much about them or the operator<< and operator>>
for that matter.


Even if you can get past the execrable look of it, it suffers from at
least 3
terrible technical problems:

1. not thread safe

2. not exception safe

3. having to acquire/release mutexes for every << operation rather
than once for
the whole expression




If it's not thread safe, why does it have to acquire mutexes?


It's not thread safe because global state can be set and reset for every
<< operation:

   a << b << setglobalstate << c << resetglobalstate << d;



Oh, and the cake topper is IOStreams performs badly, too.


Yes, but that's just a default.

std::ios_base::sync_with_stdio(false);
std::cin.tie(0);


Yeah, to make it as fast as C stdio you use C stdio. That's a ringing
endorsement!


This form of output usually causes problems with i18n as not all 
languages have the same types of grammar and sometimes the order of 
items needs to be changed to achieve a valid grammatical form in the 
translation.


Peter

Re: builtin sort

[Peter Williams]

On 09/06/13 08:54, David Nadlinger wrote:

On Saturday, 8 June 2013 at 22:25:14 UTC, Peter Williams wrote:

Shouldn't have to import std.algorithm just to sort an array.


Why not?


Because it's large with a lot of stuff unrelated to sorting.

Peter
PS A few weeks ago I would have said "large and ugly" but now I have a 
better feel for component programming it's not so ugly :-) but it's 
still large.

Re: builtin sort

[Peter Williams]

On 08/06/13 18:51, Jonathan M Davis wrote:

On Saturday, June 08, 2013 10:30:52 Stephan Schiffels wrote:

Hi,

I know it has been discussed previously to deprecate the builtin
sort. I don't know the status of this, but I observed the
following problem.

With dmd, druntime and phobos all on 2.063, this program runs
successfully on a mac:

#!/usr/bin/env rdmd

import std.stdio;

void main() {

int[] a = [5, 4, 3, 2, 1];

a.sort;
writeln(a);

}

But it fails on linux, with the line:


/nfs/users/nfs_s/ss27/Software/dlang/phobos/generated/linux/release/64/libph
obos2.a(qsort_4c4_2cc.o): In function `_adSort':
src/rt/qsort.d:(.text._adSort+0x47): undefined reference to
`qsort_r'
collect2: ld returned 1 exit status
--- errorlevel 1


When I change "a.sort" -> "a.sort()" and add import std.algorithm
everything works fine.
Does this mean that the builtin sort on Linux is broken with
2.063?


Hmm, it works just fine on my system (64-bit Linux), so I don't know why you're
seeing the problem that you're seeing.

However, we really, really need to deprecate the built-in sort - especially
when a pair of parens can make the difference between whether you call the
built-in sort or std.algorithm's sort - and it's particularly broken with
regards to Unicode.

- Jonathan M Davis



Rather than deprecate it why not fix it?  Shouldn't have to import 
std.algorithm just to sort an array.


Peter

Re: Slow performance compared to C++, ideas?

[Peter Williams]

On 07/06/13 17:28, Walter Bright wrote:

On 6/6/2013 11:30 PM, Peter Williams wrote:

I use it to make sure that my unittests are complete.


Awesome!

-cov is also useful for:

1. debugging - if your unittests can't seem to cover certain lines,
those lines might indicate a bug


That's what I meant by "unittests are complete" i.e. they cover all of 
the code.




2. performance - giving usage counts of lines tells you where the 'hot'
paths are, and those can be hand-tuned

It's also quite possible to have the compiler read the coverage report,
use it to identify the hot paths, and rearrange the code while
optimizing so that the hot paths have the fewest branches. Profile
guided optimization, if you will.


Peter
PS It would be nice if it printed the overview (i.e. % complete line)
to stdout
as well as sticking it in the coverage file report.


Please file this as an enhancement request on bugzilla.


Done.

Peter

Re: Slow performance compared to C++, ideas?

[Peter Williams]

On 07/06/13 11:12, Walter Bright wrote:

On 6/6/2013 4:56 PM, Flamaros wrote:

I think it depend of his simplicity and integration in the common D
process
development. Maybe because D build fast we can add some extra steps
during build
of the release?
And developers of companies that develop the biggest application will
be aware
of this tool and certainly have script or advanced tools to build
their software
release, adding a line during the building process seems acceptable.


Consider a trivial and effective DMD tool for debugging and improving
efficiency:

-cov

and I'm the only one I know of that uses it.


I use it to make sure that my unittests are complete.

Peter
PS It would be nice if it printed the overview (i.e. % complete line) to 
stdout as well as sticking it in the coverage file report.

Re: Inability to dup/~ for const arrays of class objects

[Peter Williams]

On 04/06/13 15:25, Peter Williams wrote:

On 04/06/13 11:56, Steven Schveighoffer wrote:

On Mon, 03 Jun 2013 20:06:14 -0400, Peter Williams
 wrote:

I use a = a[0..i] ~ v ~ a[i..$] for insertion into a sorted array as
I'm willing to pay the cost of allocation for the convenience of array
notation.  One advantage is that finding i is O(log(a.length)) instead
of O(a.length()).  I also reasoned that the compiler can use memcopy()
(or whatever its name is) to do the reallocation and therefore it
should be fairly quick.


ugh.  Sorry, the performance miser in me must object :)


I worry about correct first and then come back and worry about
efficiency.  That way I have tests in place to make sure I don't break
things during tweaking.  :-)



There are better ways to do this, using range operations.  I'm pretty
sure you could do it with std.algorithm.copy.


To insert "newElement" into array a" at index "i" where "i <= a.length",
I've come up with:

 a ~= newElement;
 if (a.length > 1 && i < a.length - 1) {
 copy(retro(a[i .. $ - 1]), retro(a[i + 1 .. $]));
 a[i] = newElement;
 }

which works (i.e. it is correct in that it passes my unit tests).  I'm
assuming allocation will only occur if it's required for the first line?

Peter
PS It's not as pretty as the original.
PPS For remove, "a = a.remove(index);" does the job.


I've since discovered std.array.insertInPlace() which does the job in a 
single call statement.


I found it interesting that std.algorithm has a remove but no insert and 
std.array has an insert but no remove.


Peter

Re: Inability to dup/~ for const arrays of class objects

[Peter Williams]

On 04/06/13 11:56, Steven Schveighoffer wrote:

On Mon, 03 Jun 2013 20:06:14 -0400, Peter Williams
 wrote:

I use a = a[0..i] ~ v ~ a[i..$] for insertion into a sorted array as
I'm willing to pay the cost of allocation for the convenience of array
notation.  One advantage is that finding i is O(log(a.length)) instead
of O(a.length()).  I also reasoned that the compiler can use memcopy()
(or whatever its name is) to do the reallocation and therefore it
should be fairly quick.


ugh.  Sorry, the performance miser in me must object :)


I worry about correct first and then come back and worry about 
efficiency.  That way I have tests in place to make sure I don't break 
things during tweaking.  :-)




There are better ways to do this, using range operations.  I'm pretty
sure you could do it with std.algorithm.copy.


To insert "newElement" into array a" at index "i" where "i <= a.length", 
I've come up with:


a ~= newElement;
if (a.length > 1 && i < a.length - 1) {
copy(retro(a[i .. $ - 1]), retro(a[i + 1 .. $]));
a[i] = newElement;
}

which works (i.e. it is correct in that it passes my unit tests).  I'm 
assuming allocation will only occur if it's required for the first line?


Peter
PS It's not as pretty as the original.
PPS For remove, "a = a.remove(index);" does the job.

Re: Inability to dup/~ for const arrays of class objects

[Peter Williams]

On 04/06/13 11:56, Steven Schveighoffer wrote:

On Mon, 03 Jun 2013 20:06:14 -0400, Peter Williams

That's great news.  When I tried to implement what I described above
it didn't go as well as planned (because I'd misunderstood how much
gets allocated) and I was thinking that what's needed is a way to tell
the compiler how much to allocate at the start.  And now you tell me
there is a way.

This is one of the things I like about learning D.  Almost every time
I say to myself "I wish there was an easier way to do this" it turns
out that there is :-).  Some of them are easier to discover than
others, though.


I added the capacity, reserve, and assumeSafeAppend array methods when I
updated the append code, it's been there for a while now, since the
beginning of 2010.  It was cited in the article mentioned earlier too.
You might want to re-read that part (it's near the end).


I'm finding that the mind tends to skip (even potentially useful) bits 
when reading about computer languages that are similar to ones that I'm 
familiar with.  I've had the same thing happen with Andrei's book i.e. 
when I discover something new I say to myself "Why didn't Andrei mention 
this?" only to discover (on rereading the pertinent section) that he did 
but it didn't register.  I've decided to reread his book cover to cover.





The appending feature of D arrays/slices is intended to be "good enough"
for most usages, not horrendously slow, but also not super-optimized for
specific purposes.

And yes, we still need linked lists, arrays are good for appending, but
not inserting :)


I use a = a[0..i] ~ v ~ a[i..$] for insertion into a sorted array as
I'm willing to pay the cost of allocation for the convenience of array
notation.  One advantage is that finding i is O(log(a.length)) instead
of O(a.length()).  I also reasoned that the compiler can use memcopy()
(or whatever its name is) to do the reallocation and therefore it
should be fairly quick.


ugh.  Sorry, the performance miser in me must object :)

There are better ways to do this, using range operations.  I'm pretty
sure you could do it with std.algorithm.copy.


I also do a = a[0..i] ~ a[i + 1..$] to remove an item but am starting
to suspect this isn't as good an idea as for the insert.  Maybe
something like:

auto tmp = a[i + 1..$];
a.length = i;
a ~= tmp;

would be more efficient?


No, because that will also reallocate,


Wouldn't the a.length = i prevent that?


just like your original.  This
one is REALLY easy to get right, because it can be done in place
(assuming a is not const/immutable).

You can even do:

memmove(&a[i], &a[i + 1], a.length - i - 1);
a.length--;

For some reason, D doesn't support overlapping moves,


Probably because there's some instances where it would be a disaster and 
explaining all the cases where you can and can't becomes too difficult 
so it's just easier to say no to all cases.



otherwise, this
would work:

a[i..$-1] = a[i + 1..$];
a.length--;

I think std.algorithm.remove can do the same thing in one line.


As I said somewhere else, there's a need for a book on Phobos.

Thanks
Peter

Re: Inability to dup/~ for const arrays of class objects

[Peter Williams]

On 04/06/13 00:57, Steven Schveighoffer wrote:

On Fri, 31 May 2013 21:04:47 -0400, Peter Williams
 wrote:

I do like the idea that "~=" is generally cheap as it potentially
makes building lists easy (is there any need for the singly linked
list in D?) and I may modify some of my code.  I've been allocating
arrays using "new array[size]" where I know that "size" will be the
max needed but that it may be too much (i.e. throwing away duplicates)
inserting into the array and then adjusting "length" to whatever I
used.  In the case, where it's highly likely that the whole array will
fit in a page I might as well allocate an empty array and use "+=".
NB there's only one copy of the array.


You can .reserve the space that you need ahead of time.  Then appending
will always deterministically go into the reserved block, and won't
reallocate.  This should be relatively quick.  It's not as quick as
pre-allocating the entire array and then writing the data directly --
you still need calls into the runtime for appending.


That's great news.  When I tried to implement what I described above it 
didn't go as well as planned (because I'd misunderstood how much gets 
allocated) and I was thinking that what's needed is a way to tell the 
compiler how much to allocate at the start.  And now you tell me there 
is a way.


This is one of the things I like about learning D.  Almost every time I 
say to myself "I wish there was an easier way to do this" it turns out 
that there is :-).  Some of them are easier to discover than others, though.




The appending feature of D arrays/slices is intended to be "good enough"
for most usages, not horrendously slow, but also not super-optimized for
specific purposes.

And yes, we still need linked lists, arrays are good for appending, but
not inserting :)


I use a = a[0..i] ~ v ~ a[i..$] for insertion into a sorted array as I'm 
willing to pay the cost of allocation for the convenience of array 
notation.  One advantage is that finding i is O(log(a.length)) instead 
of O(a.length()).  I also reasoned that the compiler can use memcopy() 
(or whatever its name is) to do the reallocation and therefore it should 
be fairly quick.


I also do a = a[0..i] ~ a[i + 1..$] to remove an item but am starting to 
suspect this isn't as good an idea as for the insert.  Maybe something like:


auto tmp = a[i + 1..$];
a.length = i;
a ~= tmp;

would be more efficient?

Peter

Re: Inability to dup/~ for const arrays of class objects

[Peter Williams]

On 31/05/13 23:58, Steven Schveighoffer wrote:

On Fri, 31 May 2013 00:48:47 -0400, Peter Williams


That makes programming much easier, doesn't it.  I'll just avoid it by
using:

a = a ~ b;

instead of:

a ~= b;


If you care nothing for performance, this certainly is a way to go.


where I think it might be an issue or is that broken too?


This is a conservative "always reallocate" methodology, it should work
just like you allocated a new array to hold a and b.


That's what I assumed.  I'm still getting used to the idea that "a = 
b" isn't just a shorthand for "a = a  b".




If a is frequently large, and b is frequently small, you will kill your
performance vs. a ~= b.


I doubt that I'll be doing it often enough (i.e. only when I think that 
it's an issue) for it to matter.  The only time I have two variables for 
the same array is when I pass one to a function as a parameter and if 
I'm intending to modify it in the function I'll pass it by reference so 
that there's no gotchas.


I do like the idea that "~=" is generally cheap as it potentially makes 
building lists easy (is there any need for the singly linked list in D?) 
and I may modify some of my code.  I've been allocating arrays using 
"new array[size]" where I know that "size" will be the max needed but 
that it may be too much (i.e. throwing away duplicates) inserting into 
the array and then adjusting "length" to whatever I used.  In the case, 
where it's highly likely that the whole array will fit in a page I might 
as well allocate an empty array and use "+=".  NB there's only one copy 
of the array.


Peter

Re: Inability to dup/~ for const arrays of class objects

[Peter Williams]

On 31/05/13 12:07, Steven Schveighoffer wrote:

On Thu, 30 May 2013 20:05:59 -0400, Peter Williams
 wrote:


On 30/05/13 16:21, Ali Çehreli wrote:

On 05/29/2013 06:54 PM, Peter Williams wrote:
 > I find the mechanism described in the article a little
disconcerting and
 > it certainly needs more publicity as it's a bug in waiting for the
 > unwary.

It certainly is disconcerting. Performance have played a big role in the
current semantics of slices.


I should have added that it was the non determinism that disconcerted
me.  It doesn't really affect me personally as a programmer now that I
know about it as I can just avoid it.  But it blows out of the water
any hopes of having "proveably correct"  non trivial code.


I think this is an overstatement.  It depends heavily on what you are
doing, and most usages will be correct.


All uses have to be correct if you want "provably correct" otherwise you 
just get "mostly correct".




You can achieve deterministic behavior depending on what you are looking
for.  For certain, you can tell without any additional tools that an
append will not reallocate if the capacity is large enough.



That makes programming much easier, doesn't it.  I'll just avoid it by 
using:


a = a ~ b;

instead of:

a ~= b;

where I think it might be an issue or is that broken too?

I toy in my mind with the idea that the difference between dynamic 
arrays and slices should be that slices are read only and if you write 
to them they get reallocated and promoted to dynamic array (kind of like 
copy on write with hard linked files).  But I'm sure that would just 
create another set of problems.  Also I imagine that it's already been 
considered and discarded.  BTW the slice "notation" could still be used 
for assigning to sections of an array.


Peter

Re: The stately := operator feature proposal

[Peter Williams]

On 30/05/13 18:43, Russel Winder wrote:

On Thu, 2013-05-30 at 02:19 +0200, MrzlganeE wrote:
[…]

In places where I write a bunch of short mathy code, I do not
want to use 'auto'. The := operator would allow to declare a
variable, deduce its type, and define its value.

void main() {
  x := 1;
  y := 2.0;
  z := x * y;
  y = 3.0;
}

[…]


  for (i := 0; i < 24; i++) {
  }


Go does exactly this, and it is good.

Less is more.



Except in the case of Go with their inane policy of injecting ';' into 
the lexical analyser at the end of lines for the sake of brevity.


Peter

Re: A different tuple syntax

[Peter Williams]

On 30/05/13 23:14, eles wrote:

On Thursday, 30 May 2013 at 13:02:24 UTC, bearophile wrote:

Frank Fuente:
The syntax with tup() is longer but less noisy.


I prefer tup() over the @{} thing, although I would like to have
something that looks like "a syntax" instead of "a function".



Yes, don't over use {} as they'll be need for sets when they're added :-)

Peter

Re: Inability to dup/~ for const arrays of class objects

[Peter Williams]

On 30/05/13 16:21, Ali Çehreli wrote:

On 05/29/2013 06:54 PM, Peter Williams wrote:
 > Wouldn't a better rule for pass by value be that any changes to
 > the data part of the array (including assignment to an element) causes
 > reallocation of the entire data portion.

The type of a slice parameter is not different than a local slice
variable. Since we wouldn't want an entire copy of the elements due to
an element mutation:

 int[] whole = // ...;
 int[] firstHalf = whole[0 .. $/2];
 firstHalf = 42;// this should affect whole

Moving the last two lines to a new function should not change meaning:

 int[] whole = // ...;
 setFirstHalf(whole, 42);  // should still affect whole


I think that setFirstHalf() should only effect whole if it's passed in 
by reference.  I certainly intend to adopt that practice in my D code.


Peter

Re: Inability to dup/~ for const arrays of class objects

[Peter Williams]

On 30/05/13 16:21, Ali Çehreli wrote:

On 05/29/2013 06:54 PM, Peter Williams wrote:
 > I find the mechanism described in the article a little disconcerting and
 > it certainly needs more publicity as it's a bug in waiting for the
 > unwary.

It certainly is disconcerting. Performance have played a big role in the
current semantics of slices.


I should have added that it was the non determinism that disconcerted 
me.  It doesn't really affect me personally as a programmer now that I 
know about it as I can just avoid it.  But it blows out of the water any 
hopes of having "proveably correct"  non trivial code.


Peter

Re: Why UTF-8/16 character encodings?

[Peter Williams]

On 31/05/13 05:07, Walter Bright wrote:

On 5/30/2013 4:24 AM, Manu wrote:

We don't all know English. Plenty of people don't.
I've worked a lot with Sony and Nintendo code/libraries, for instance,
it almost
always looks like this:

{
   // E: I like cake.
   // J: ケーキが好きです。
   player.eatCake();
}

Clearly someone doesn't speak English in these massive codebases that
power an
industry worth 10s of billions.


Sure, but the code itself is written using ASCII!


Because they had no choice.

Peter

Re: Inability to dup/~ for const arrays of class objects

[Peter Williams]

On 30/05/13 10:49, Peter Williams wrote:

On 30/05/13 09:45, Ali Çehreli wrote:

Yes, simply pass-by-reference. Not expensive at all. There may be
surprises though; you may want to read this article:

   http://dlang.org/d-array-article.html


Very informative article.


Thinking about this some more, it seems I still need the const even with 
pass by value to reassure the caller that his array won't be altered. 
So the problem doesn't go away it just changes slightly.


I find the mechanism described in the article a little disconcerting and 
it certainly needs more publicity as it's a bug in waiting for the 
unwary. Wouldn't a better rule for pass by value be that any changes to 
the data part of the array (including assignment to an element) causes 
reallocation of the entire data portion.


Peter

Re: Inability to dup/~ for const arrays of class objects

[Peter Williams]

On 30/05/13 09:45, Ali Çehreli wrote:

Yes, simply pass-by-reference. Not expensive at all. There may be
surprises though; you may want to read this article:

   http://dlang.org/d-array-article.html


Very informative article.

Thanks
Peter

Re: Why UTF-8/16 character encodings?

[Peter Williams]

On 30/05/13 08:40, Entry wrote:

My personal opinion is that code should only be in English.


But why would you want to impose this restriction on others?

Peter

Re: Inability to dup/~ for const arrays of class objects

[Peter Williams]

On 30/05/13 02:17, Ali Çehreli wrote:

On 05/28/2013 08:43 PM, Peter Williams wrote:

 > One place I'm using it is for managing symbols (look ahead sets, etc) in
 > a parser generator.  The symbols' permanent home is in an associative
 > array indexed by their name (which is also included in the symbol
 > object) but they may belong to many look ahead sets.

Have you considered Rebindable?



No. Never heard of it before :-)

But, having now read the documentation, I don't think it meets my needs.

We need a book on the standard library.

Thanks
Peter

Re: Inability to dup/~ for const arrays of class objects

[Peter Williams]

On 29/05/13 19:40, monarch_dodra wrote:


The problem is that you are missing a FUNDAMENTAL difference between C++
and D. C++'s const merely says: "Though shalt not modify this value",
whereas D's means "This object's value WILL remain constant, until the
end of time, and under no circumstance can it ever be modified. Oh. And
so will everything it references".


More likely C constness but yes I am still learning D.  I suspect that a 
lot of my D code currently looks like C code using D syntax.  As I learn 
more I'll go back and change the code to be more D like than C like 
(especially as this usually leads to major simplifications).


I'm also starting to suspect that my understanding of how C arrays are 
passed as arguments to functions is affecting my desire to use const 
when passing them in and this may be misguided.  I've been trying to 
find out how non ref array arguments are passed to functions in D but 
can't find any documentation on it.  If doing that is not much less 
efficient than passing by ref (and isolates the external representation 
of the array from anything I do) then I can stop using ref and the 
problem goes away.


Peter

Re: Inability to dup/~ for const arrays of class objects

[Peter Williams]

On 29/05/13 13:59, Steven Schveighoffer wrote:


You can't use const elements.  And for good reason -- the elements are
not const, and cannot be considered const by the set.

Use mutable data, and make the *key* part of the data const.


My first implementation does that and it's great for that one 
application.  All the complications arose when I went back to try and 
bulletproof it and make a set implementation that is generally useful 
rather than just for the application it was designed for.


I may just have to accept that two separate implementations are needed 
and that I have to give some thought about how to maximise the shared 
code between them.



 If you
wish, you can place inout on the indexing function, which should
guarantee that during that function the data is not molested.  Then you
basically have to hand-verify the insertion function does not change the
data.


I always (try to) do hand verification :-).  Once I even toyed with code 
proofs (a la Gries, ISBN 0-387-90641-X) but that rapidly becomes boring 
in practice even when you have language constructs (such as Eiffel's 
loop) which are designed with such proofs in mind.




That's the best D can do, and it's pretty good considering what other
alternatives there are.


Yes. I agree - a type attribute system that could say everything we want 
to say would be very complex.  Nevertheless, D has room for improvement 
e.g. more expressive contracts are possible.


Peter
PS There seems to be a reluctance to fix problems in D if it will break 
existing code.  I would opine that the code that would be broken is 
already broken.  I would also opine that fixing the problems now will 
break less code than fixing them later.

Re: Inability to dup/~ for const arrays of class objects

[Peter Williams]

On 29/05/13 11:31, Steven Schveighoffer wrote:



I'm implementing sets and the concept is sets of objects not sets of
the values in the objects.  I want to be able to initialize sets using
arrays and I'm promising that I won't change the array or its
contents.   I'm also trying to promise that I won't (inside the set
implementation) make any changes to individual objects.  But I'm not
promising that they won't be changed by other code that has access to
them.  The invariant (I wrote) for the sets implies that any changes
made by that code can't change the sort order of the objects.


Then you are trying to make a *momentary* guarantee.


Almost.  I'm also saying I won't change it any time within the set.



In essence, you want to transform the array into a set, but still
guarantee that the underlying data hasn't changed.


More or less. The set code won't change it something else might.



This is very difficult to express with the type system.


I'm starting to realize this :-)

I've always been frustrated in other languages by const (and friends) 
being inadequate for saying what I want to say.



The closest you
can get is inout, which *might* be able to do it.

For example:

inout(T)[] copyIt(T)(inout(T)[] arr)
{
// this is quirky, but it's the easiest way to do it without an
equivalent .dup for inout
inout(T)[] result;
result ~= arr;
return result;
}

Now, if you pass in mutable, you get mutable.  If you pass in const, you
get const.  If you pass in immutable, you get immutable.

I say *might* because I don't know what your code is doing, or how your
set type actually looks.  It may be logical, but impossible to currently
express.  inout still has some room for improvement (and so does the
whole const system in general).


No, I really don't want copies although I can see that might have it's
uses in another application.  It's the mathematical concept of sets
that I'm trying for not just containers.  I.e. it's a way of selecting
groups of objects, combining groups without duplicates, etc.


Another option is to simply define your types as "immutable" types.
That is, specify the data inside is immutable, but the class itself is not.


No.  I need to be able to make changes to the objects (that doesn't 
effect their order).  It's kind of like an associative array (which I 
did consider as a mechanism for doing what I wanted) but without 
splitting the object into a key/value pair.


One place I'm using it is for managing symbols (look ahead sets, etc) in 
a parser generator.  The symbols' permanent home is in an associative 
array indexed by their name (which is also included in the symbol 
object) but they may belong to many look ahead sets.  Usually, 
processing that requires access to attributes of the symbol (other than 
the key) occurs when processing one of the look ahead sets and going 
looking for the symbol table looking for the data is an unnecessary 
complication (not to mention an efficiency hit).  Having exactly one 
object per symbol but still being able to have it multiple sets is a big 
efficiency gain especially when it comes to making changes to the 
ancillary data as you only have to change it in one place.




e.g.:

class C
{
immutable int c;
this(int x) { c = x;}
}

You are hitting a very common pain-point for const/immutable, for which
there is really not a good answer currently.


I agree.

This happens every time I try a new language.  I get all excited about 
making my code bulletproof only to be mugged by reality. :-)  In the 
end, it comes down to coding carefully.


Peter

Re: Inability to dup/~ for const arrays of class objects

[Peter Williams]

On 29/05/13 09:58, Steven Schveighoffer wrote:

In fact, const(T)[] applies ONLY to the data in the array, the array
itself is not const.  A fully const array is:

const(T[])

Which cannot be appended to or modified.


Thanks, I'll change my code.



However, a const(T[]) implicitly casts to a const(T)[].


If this behaviour is a deliberate design decision


It is


I'll accept that and (probably) modify my code to use (cast(T[])).dup
in all cases.  (At the moment, I'm using a single mixin template to
handle this issue and the inability to use ==, !=, < and friends with
constant class objects. When that problem goes away I'll do the above
modifications.)


This is not a good idea.  You are circumventing const.


Unfortunately, I have to circumvent const just to use ==, <=, etc in the 
current incarnation of D.  So this won't make things worse.



 What you want is a deep copy.


No, I don't.

I'm implementing sets and the concept is sets of objects not sets of the 
values in the objects.  I want to be able to initialize sets using 
arrays and I'm promising that I won't change the array or its contents. 
 I'm also trying to promise that I won't (inside the set 
implementation) make any changes to individual objects.  But I'm not 
promising that they won't be changed by other code that has access to 
them.  The invariant (I wrote) for the sets implies that any changes 
made by that code can't change the sort order of the objects.




In all likelihood, the problem could be that you are using classes and
really should be using structs.


No, I really don't want copies although I can see that might have it's 
uses in another application.  It's the mathematical concept of sets that 
I'm trying for not just containers.  I.e. it's a way of selecting groups 
of objects, combining groups without duplicates, etc.


Peter

Re: Why UTF-8/16 character encodings?

[Peter Williams]

On 29/05/13 09:57, H. S. Teoh wrote:

On Wed, May 29, 2013 at 09:33:32AM +1000, Peter Williams wrote:

On 28/05/13 19:12, Jacob Carlborg wrote:

On 2013-05-28 08:00, Manu wrote:


Is there anywhere other than America that doesn't?


Canada, Jamaica, other countries in that region?



Last time I looked Canada was in America (which is a continent not a
country). :-)

[...]

If you say that to a Canadian to his face, you might get a hostile (or
faux-hostile) reaction. :)

Up here in the Great White North, we like to think of ourselves as
different from our rowdy neighbours to the south (even though we're not
that different, but we won't ever admit that :-P). And yes, "America"
means USA up here (and "American" especially means USian, as distinct
from Canadian), even though we all know that technically it refers to
the continent, not the country.


Last time I was there (about 40 years ago) Canadians didn't seem that 
touchy. :-)


Peter

Re: Why UTF-8/16 character encodings?

[Peter Williams]

On 28/05/13 19:12, Jacob Carlborg wrote:

On 2013-05-28 08:00, Manu wrote:


Is there anywhere other than America that doesn't?


Canada, Jamaica, other countries in that region?



Last time I looked Canada was in America (which is a continent not a 
country). :-)


Peter

Re: Inability to dup/~ for const arrays of class objects

[Peter Williams]

On 28/05/13 23:41, Steven Schveighoffer wrote:

On Sat, 25 May 2013 23:58:39 -0400, Peter Williams
 wrote:


Is the inability to use dup and ~ with const arrays of class objects a
deliberate design restriction?  I couldn't find mention of it in the
specification or Andrei's book and only discovered it the hard way.


It has to be.  There is no cdup.

For any const(T)[] x, the type of x.dup is T[].


Yes, that's why I was doing the dup.  I wanted a non const copy of the 
array.



 Because this would mean
that you would remove const, you cannot do that.


I find that dup works for const T[] when T is not a class (although I 
haven't tried it with pointers).  This means I write two versions of my 
code - one for classes (which does (cast(T[])).dup) and one for the rest.



 Nor can you idup,
since implicit conversion to immutable is not possible.

As far as I know, ~ works with const arrays of class objects.  Can you
give a case where it fails?


Looking at my code that caused me to ask this question, I've realised 
that I'm appending a const object onto a no const array.  Once again 
this works for non class objects but not for classes.


I can see why this might be the case as non class objects are probably 
copied by value where the class objects are pointers and the constness 
applies to the items in an array as well the array itself.


If this behaviour is a deliberate design decision I'll accept that and 
(probably) modify my code to use (cast(T[])).dup in all cases.  (At the 
moment, I'm using a single mixin template to handle this issue and the 
inability to use ==, !=, < and friends with constant class objects. 
When that problem goes away I'll do the above modifications.)


This is the type of issue that can come as a surprise when you have a 
working/tested code that suddenly stops compiling when you use it with 
classes.  So a heads up in the documentation would be useful.


Thanks for your response,
Peter

Re: Why UTF-8/16 character encodings?

[Peter Williams]

On 28/05/13 13:22, David Eagen wrote:

On Tuesday, 28 May 2013 at 01:38:22 UTC, Peter Williams wrote:



So you're going to spell check them all to make sure that they're
English?  Or did you mean ASCII?

Peter


That's it. I'm filing a bug against std.traits. There's a unittest there
that with a struct named "Colour". Completely unacceptable.


Except here in Australia and other places where they use the Queen's 
English :-)


Peter

Re: More on "Component Programming"

[Peter Williams]

On 28/05/13 11:50, bearophile wrote:

Peter Williams:


Are the () necessary on sort?


If you don't use () I think you call the slower, not flexible and buggy
built-in sort. I think it's already deprecated. Maybe I am wrong...


Ah.  Does that mean that import.algorithms is need to use sort()?





PS Now I've found this I can go back and simplify all the code where I
iterated over associative arrays in key order by getting the keys and
the sorting them separately.


I don't fully understand.


I'm assuming here that it's safe to call sort() on the .keys property of 
the dynamic array.  This enables me to go:


foreach (key; aa.keys.sort()) {...}

instead of the much more complex code I'm currently writing which gets 
the keys, sorts them and then uses them in the foreach.  I had actually 
written a generic function to do all of that but now find all the work 
was unnecessary :-).


As I learn more about D I'm finding I can go back and simplify a lot of 
my code.  I'm going to reread Andrei's book to see what I missed the 
first time.


Peter
PS I think I need to read more about component programming as I'm 
beginning to suspect I don't understand it fully.

Re: Why UTF-8/16 character encodings?

[Peter Williams]

On 28/05/13 09:44, H. S. Teoh wrote:


Since language keywords are already in English, we might as well
standardize on English identifiers too.


So you're going to spell check them all to make sure that they're 
English?  Or did you mean ASCII?


Peter

Re: More on "Component Programming"

[Peter Williams]

On 28/05/13 10:37, bearophile wrote:

.map!(words => words
   .classify!q{ a
.dup
.representation
.sort()
.release


Also, let's kill the built-in sort already :-)



But I just found it and started using it. :-)

I was contemplating writing my own sort function as the ones in 
std.algorithm didn't meet my needs (or using them was too messy) until I 
discovered this feature.


Are the () necessary on sort?  I found:

auto sorted_array = an_array.dup.sort;

worked.

Peter
PS Now I've found this I can go back and simplify all the code where I 
iterated over associative arrays in key order by getting the keys and 
the sorting them separately.

PPS Every time I discover one of these features I like D even more.

Re: [article] Language Design Deal Breakers

[Peter Williams]

On 26/05/13 21:13, Paulo Pinto wrote:

Am 26.05.2013 09:36, schrieb Walter Bright:

On 5/26/2013 12:03 AM, Paulo Pinto wrote:

After being a Turbo Pascal heavy user, C always felt backwards to me
with its
weak types, lack of proper strings, modules and namespaces.


I had the opposite experience. Being a Pascal user from the late 70's, I
hated Pascal's limitations. A friend loaned me K+R and it was like
someone opened a window. I never wrote another line of Pascal; I threw
it under the bus, and couldn't work up any interest in TP (which came
along later).

Proper strings? Those length-prefixed ones that couldn't be longer than
255 characters? Argh. C botched them too with 0 terminated ones, but at
least they were usable.



Pascal string limitations were only an issue in classic Pascal, both
Extend Pascal its sucessors Modula-2 and so on follow a model similar to
what D offers.

Now it is too late for it, but at the time C could have stayed as
powerful as it is while offering:

- proper modules, or at least namespaces

- no automatic conversions between arrays and pointers. how hard it is
to write &a[0]?

- arguments by reference, no need to check for null for every parameter

- strong typed enumerations

- memory allocation without requiring the developer to use sizeof
everywhere

- strings similar to what D has

- proper arrays, after all the compilers for other languages always
offered control over when bound checking code was generated

In the end, same syntax, just some semantic improvements on the type
system.

But now it is too late, we only have modern C++ with its warts, or
hopefully D, Rust, Go, C#, or something else as possible replacement.

However, given that C and UNIX are one and only, it will outlive us all.


Don't forget that Pascal was only meant to be a teaching language.  That 
it was used for more than that says more about the other languages 
available at the time than it does Pascal.


Peter

Re: [article] Language Design Deal Breakers

[Peter Williams]

On 26/05/13 15:44, H. S. Teoh wrote:

On Sun, May 26, 2013 at 01:27:55PM +1000, Peter Williams wrote:

On 26/05/13 11:59, Nick Sabalausky wrote:

[...]

Forget waiting for a huge improvement, I'd have been happy to
ditch C++ even for a small improvement. C++ is such a pain IMO that
using it has about as much inertia as ice skates on concrete.


I found shifting from C++ to C an improvement.  (Yes, I learnt C++
before I learnt C.)  I should mention that this was back in the mid
90s and C++ may have improved since then :-).

[...]

You're not the only one who felt that way. At my day job we also
"upgraded" from C++ back to C. I've often ranted about our horrific
experience with a hugely over-engineered C++ system that can literally
do *anything*... except that nobody understood how to use the thing. It
had dtors with side-effects that did useful work, for instance, and
there were so many levels of abstraction it was bordering on insanity.
Once I had to make a function call to said horrible code... it involved
going through 6 layers of abstraction, two of which were fwrite()ing
function arguments to a temporary file, then fork() and exec()ing an
auxilliary utility that fread() the arguments back, and *then*
dispatched them across an IPC link...


Makes debugging fun doesn't it? :-)



We're now back in C-land, and boy the code is much cleaner, and
*faster*, even though it's a lot harder to read and more tedious to
maintain.

Like I've said many times before, the only way I found coding in C++
tolerable was to use it as "C with classes". Trying to do real OO in C++
is an exercise in masochism. Even Java with its baroque verbosity and


Amen to that.  One reason I've avoided Java is that I found the signal 
to noise ratio in the source code VERY low and this made reading such 
code to find the bit that actually did something difficult.  I am (or 
was), however, a fan of the Java Virtual Machine (JVM) because it offers 
"run anywhere" functionality.



prolific boilerplates beats C++ hands-down in this respect. And don't
even mention templates, which are already nasty enough to work with in
simple generic types; they are utter monstrosities when you start
getting into CTFE and compile-time codegen. D templates, CTFE, and
mixins, by contrast, are actually *pleasant* to work with.


I agree.  Although I'm still learning D I'm finding it a pleasure with a 
very high signal to noise ratio in source code.  Plus most features just 
work like one wishes the would.


Peter

Inability to dup/~ for const arrays of class objects

[Peter Williams]

Is the inability to use dup and ~ with const arrays of class objects a 
deliberate design restriction?  I couldn't find mention of it in the 
specification or Andrei's book and only discovered it the hard way.


Thanks
Peter

Re: [article] Language Design Deal Breakers

[Peter Williams]

On 26/05/13 11:59, Nick Sabalausky wrote:

On Sun, 26 May 2013 00:50:28 +0200
Klaim - Joël Lamotte  wrote:

I think this have not been posted yet around here but might be
interesting to the D community as it is actually criticizing several
languages including D but with an interesting aproach:

http://sebastiansylvan.wordpress.com/2013/05/25/language-design-deal-breakers/



Hah, now that's my kind of dude:

"I know you’re supposed to be diplomatic and claim that there’s two
sides to this story, and no real right answer, but really people who
think dynamic typing is suitable for large scale software development
are just nuts. They’ll claim it’s more flexible and general but that’s
just nonsense in my opinion."

Classic :) It's weird when I see my thoughts written by someone else
(and worded better that I would have), but he nailed it there.

I do think his "inertia" with C++ is cranked way into overdrive,
though.


Yes.


Forget waiting for a huge improvement, I'd have been happy to
ditch C++ even for a small improvement. C++ is such a pain IMO that
using it has about as much inertia as ice skates on concrete.


I found shifting from C++ to C an improvement.  (Yes, I learnt C++ 
before I learnt C.)  I should mention that this was back in the mid 90s 
and C++ may have improved since then :-).


Peter

Re: Out contracts: how to refer to objects' start state

[Peter Williams]

On 26/05/13 11:47, Andrei Alexandrescu wrote:

On 5/25/13 9:18 PM, Adam D. Ruppe wrote:

On Sunday, 26 May 2013 at 01:12:35 UTC, Andrei Alexandrescu wrote:

On 5/25/13 9:03 PM, Andrej Mitrovic wrote:

On 5/26/13, Andrei Alexandrescu

in { auto oldLen = this.length; }

out { assert(this.length == in.oldLen + 1); }



Since every in.xyz expression could access an arbitrary method of the
old object,


Here, in.oldLen refers to the local variable you defined in the in{}
scope, as opposed to plain oldLen which would be searing the out{} scope.


Ohh, I see. Yes, that could work.


That revelation also answers my question about how it could break code.

Peter

Re: Out contracts: how to refer to objects' start state

[Peter Williams]

On 26/05/13 10:43, Andrei Alexandrescu wrote:

On 5/25/13 8:38 PM, Peter Williams wrote:

For some class methods, to express comprehensive out{} contracts it is
necessary to be able to refer to the state of the class object before
the operation as well as after it e.g. if the method adds something to a
container you need to be able to specify that nothing was accidentally
deleted from the container during the method. I've scoured the language
specification and Andrei's book for advice on how to do this without any
luck.

Can it be done and, if so, how?

Thanks
Peter


Unfortunately we don't have a solution to that. A while ago I proposed
that the "in" and "out" contracts share the same scope. That would allow
us to do:

class A {
   void fun()
   in { auto oldLen = this.length; }
   out { assert(this.length == oldLen + 1); }
   body { ... }
}

That was technically difficult to do back then, and fell by the wayside.


That looks like a good solution to me.


Today it would break too much code to introduce even if feasible.


How would it break code?  I've tried to imagine how but have failed.

Peter

Out contracts: how to refer to objects' start state

[Peter Williams]

For some class methods, to express comprehensive out{} contracts it is 
necessary to be able to refer to the state of the class object before 
the operation as well as after it e.g. if the method adds something to a 
container you need to be able to specify that nothing was accidentally 
deleted from the container during the method.  I've scoured the language 
specification and Andrei's book for advice on how to do this without any 
luck.


Can it be done and, if so, how?

Thanks
Peter

Re: Ideal D GUI Toolkit

[Peter Williams]

On 23/05/13 16:36, Jacob Carlborg wrote:

On 2013-05-23 01:51, Peter Williams wrote:


That is indeed the case.  I avoid all things Apple as my experience has
been that they seem to think they still own a device after they've sold
it to me.


I can understand that. But if we are to create something like this
thread suggest I would say that it's almost irresponsible to not try all
the alternatives. Ok, it might not be that easy to try the Apple stuff,
need the correct hardware and so on. Yes, there are workarounds as well.


If I had been advocating the banning of GUI builders that would be the 
case but I was just saying I found them not very useful once I was 
familiar with the API proper.





What you describe isn't a very attractive work flow (for me).  Using
PyGTK direct I just use normal OOP techniques to extend widget classes
and adding a widget to a window is very simple operation (1 statement)
and certainly doesn't need a GUI to achieve it.


You will need do the same thing in Xcode as well. What I described here
was how to add a custom view, that you already have created using
inheritance, using the GUI builder to a window. I can add as well that
you're not forced to use the GUI builder, but it's generally easier.


For you maybe.  My experience has been the opposite.  I'm not proposing 
that you shouldn't be able to use such a tool if that's your preference 
just that it shouldn't be the only way to create a GUI.


Peter
PS I'm a great believer in GUIs and have spent a great deal of time 
writing GUI wrappers for tools such a quilt, mercurial and git just to 
avoid having to type the same thing over and over at the command line. 
But I always include a mechanism for typing in commands directly as 
cases always arise where the GUI can't do exactly what you want.

Re: Ideal D GUI Toolkit

[Peter Williams]

On 23/05/13 17:29, Diggory wrote:


What's great about it is you can develop your program with having to
mess about with keys or anything to do with i18n, just remember to call
"gettext()" and when your done it's already ready for translations to be
added. Most other schemes require you to create a key before you can do
anything which is a massive waste of time while developing when you may
end up changing it numerous times or end up not even needing it.


Exactly.  From the programmers POV i18n with gettext() is a breeze.

Peter
PS retrofitting i18n using gettext() is equally painless to the point of 
being boring.

Re: Ideal D GUI Toolkit

[Peter Williams]

On 23/05/13 17:19, Jacob Carlborg wrote:

On 2013-05-23 08:27, Peter Williams wrote:


An example of how I would envisage gettext being used in D is:

writefln(gettext("%s: unknown variable at line %s"), filename,
linenumber);

It is a common practice, to define a macro (or equivalent) _(arg) as an
alias for gettext(arg) (and N_(arg) for gettext_noop(arg)) because
people like brevity.

I would suggest using the gettext() functionality for i18n but design
the notation used within programs (to access that functionality)
according to what best suits the D paradigm.


Is the text you want to translate the actual key?


Yes.


That sounds very
stupid. What if I need to change the text?



Well. the translation will also need to be changed to any extra id that 
you'd given the original string is now useless.


Believe me, the give the strings an extra id idea has been tried (many 
times) and it failed badly (compared to gettext's model).


Peter

Re: Ideal D GUI Toolkit

[Peter Williams]

On 23/05/13 11:23, Adam D. Ruppe wrote:

I've never actually done i18n so I might be full of crap, but I think a
nice way to do it would be something along these lines:

1) (optionally) all printing functions actually take a different type
than just plain string, forcing you to use the translation function


Not all strings should be translated.  So you need a way to say which 
ones do need to be translated.  Many schemes have been invented over the 
years (by Sun, Microsoft, etc.) but most of them died when gettext() 
came along as they were all very complex compared to gettext() and 
usually involved creating digests and giving strings id numbers etc. 
which rapidly became a maintenance nightmare.


The key simplicity of gettext() is the each string is its own identifier 
and notification that a string needs translating and doing the 
translation call is the one piece of code.


There is a minor complication with using strings declared as variables 
in COMPILED languages as the translation can't be done at compile time 
so they have two notations:


1. what I described above it gettext('string') means mark 'string' for 
translation and also return me the translation of 'string' i.e. a 
compile time meaning and a runtime meaning
2. a second template gettext_noop('string') which just means mark the 
string for translation and that's all.  In C and C++ this is usually 
just a macro that does nothing.  Then when you need the string variable 
later on you use gettext() to get the translation.  NB 
down in the guts it's just the contents of the string that is used as 
the key in the translation mechanism and there's no need to track the 
fact that it contains a translatable string.  Gettext() never fails and 
if it's called with a string that it cant find the translation for it 
just returns its argument unchanged.  In D, I imagine the best way to do 
this would be to have some sort of qualifier that could be used as part 
of the string variable declaration to tag it as a target for translation.


One of the things that is useful when doing i18n is having writef, etc. 
have the ability to specify which arguments should be placed where in 
the format string as it sometimes necessary to reorder them in order to 
make a translation that makes sense in the target language (as not all 
languages have a subject-verb-object grammar e.g. Yoda).


An example of how I would envisage gettext being used in D is:

writefln(gettext("%s: unknown variable at line %s"), filename, linenumber);

It is a common practice, to define a macro (or equivalent) _(arg) as an 
alias for gettext(arg) (and N_(arg) for gettext_noop(arg)) because 
people like brevity.


I would suggest using the gettext() functionality for i18n but design 
the notation used within programs (to access that functionality) 
according to what best suits the D paradigm.


Peter

Re: Ideal D GUI Toolkit

[Peter Williams]

On 22/05/13 07:27, Diggory wrote:

On Tuesday, 21 May 2013 at 18:59:08 UTC, Jacob Carlborg wrote:

I would expect that the system needs to be designed from the ground up
with support for something like internationalization. There are
probably other features were this is true as well.


Of course, although I think internationalization is actually not one of
them.

We could implement something like https://en.wikipedia.org/wiki/Gettext


I agree.  I would very much like to see a D implementation of gettext() 
as IMHO it is the best i18n mechanism around - simple and easy to use.


I also think that putting i18n hooks in your code is not just good 
manners but good sense as it widens your potential customer base.  I do 
it with all of my PyGTK GUIs (as Python's standard has gettext()) but 
don't do any l8n as I figure that's not my responsibility.


> in D which would be great because unlike Gettext we wouldn't have to
> have a separate compiler to generate the equivalent of the .pot file, we
> should be able to do that as part of the normal compilation process.

This would be great.  I had been toying with the idea of making a tool 
to do that but if the compiler could do it things would be greatly 
simplified.


Peter

Re: Ideal D GUI Toolkit

[Peter Williams]

On 22/05/13 16:44, Jacob Carlborg wrote:

On 2013-05-22 07:00, Peter Williams wrote:


My experience (with PyGTK) is that GUI building tools actually make the
task harder not easier (once you become familiar with the API).  Of
course, things may have changed since I last used such a tool but I
doubt it.


Then you obviously haven't used Interface Builder/Xcode on Mac OS X.
It's a great tool for window building.


That is indeed the case.  I avoid all things Apple as my experience has 
been that they seem to think they still own a device after they've sold 
it to me.


Most of my experience with such tools was with Glade.

I found that Glade produced a lot of code to do very little.




Having said that I have to admit that I've implemented my own "list/tree
specification" mechanism for that particular job because it made it
easier to find where to make changes.  In my defence, last time I used
one of the GUI building tools it contained no support for building lists
and trees so making my own made sense.


If the tool didn't support trees you obviously used a bad tool.


Probably.


In Xcode
you can drag in a standard view, then change the implementation class.
This allows you to add your custom views to the window using the GUI
builder. It used to have plugins for this but they were removed in Xcode 4.



What you describe isn't a very attractive work flow (for me).  Using 
PyGTK direct I just use normal OOP techniques to extend widget classes 
and adding a widget to a window is very simple operation (1 statement) 
and certainly doesn't need a GUI to achieve it.


The part of creating a tree that I use my specification mechanism for is 
defining/setting up the columns and setting options on them which I 
don't think would be made easier using a GUI.


Peter

Re: Ideal D GUI Toolkit

[Peter Williams]

On 21/05/13 16:35, Nick Sabalausky wrote:

On Mon, 20 May 2013 23:21:28 -0700
Brad Roberts  wrote:


On 5/20/13 9:49 PM, Peter Williams wrote:


Yes, if D aspires to be a systems programming language it can't keep
relying on wrappers around C/C++ libraries (especially C++).  In the
long term, it should be D all the way down to the OS API.


You wrote this as if not using c and c++ libraries is a predicate for
being a systems language.  It's not.

What's with the D community's (yes, I'm over generalizing some)
not-invented-here syndrome?


Conditioned aversion to C++? (half-serious)


Avoiding the incredible body of existing
code out there that's accumulated over the decades is foolhardy and
narrow sighted.  Are all c and c++ libraries great bodies of code,
absolutely not.  Is some of the code that predates D worth reusing,
yup.


Don't think of it as reinventing.  Think of it as reimplementing.

After all that's what we've done with wheels over the millennia.

Peter

Re: Ideal D GUI Toolkit

[Peter Williams]

On 21/05/13 17:24, Jacob Carlborg wrote:

On 2013-05-21 05:32, Tyler Jameson Little wrote:


As for my opinionated ideals (doesn't affect the overall design much):

* no XML (yaml maybe, but XML just isn't user-friendly)


Do people actual "code" in the markup. Isn't that just for a GUI
building tool.



My experience (with PyGTK) is that GUI building tools actually make the 
task harder not easier (once you become familiar with the API).  Of 
course, things may have changed since I last used such a tool but I 
doubt it.


Having said that I have to admit that I've implemented my own "list/tree 
specification" mechanism for that particular job because it made it 
easier to find where to make changes.  In my defence, last time I used 
one of the GUI building tools it contained no support for building lists 
and trees so making my own made sense.


Peter

Re: Ideal D GUI Toolkit

[Peter Williams]

On 21/05/13 16:21, Brad Roberts wrote:

On 5/20/13 9:49 PM, Peter Williams wrote:


Yes, if D aspires to be a systems programming language it can't keep
relying on wrappers around C/C++ libraries (especially C++).  In the
long term, it should be D all the way down to the OS API.


You wrote this as if not using c and c++ libraries is a predicate for
being a systems language.  It's not.


It is for me. I also won't count D as a systems language until DMD is 
implemented in D.




What's with the D community's (yes, I'm over generalizing some)
not-invented-here syndrome?  Avoiding the incredible body of existing
code out there that's accumulated over the decades is foolhardy and
narrow sighted.


I did say "in the long term".


Are all c and c++ libraries great bodies of code,
absolutely not.


I am not a fan of C++ (and don't really trust C++ libraries).  I went to 
C++ from Modula-2 due to job constraints but eventually ditched it and 
moved on to C - yes, I went from C++ to C.  The main reasons were that I 
felt C++ caused more problems than it cured.  Plain C is a perfectly 
good language for OOP as GTK+ demonstrates and there's no need for all 
the complexity that comes with C++.



 Is some of the code that predates D worth reusing, yup.


Yes, but "in the long term" it should be replaced by D code so that you 
get all the many advantages (better testing, contracts, simplicity, 
etc.) that brings.  Redo the ones that suck first but do them all 
eventually.


Peter

Re: Ideal D GUI Toolkit

[Peter Williams]

On 21/05/13 13:46, Tyler Jameson Little wrote:

I'm completely willing to head up the initial development. I probably
won't get anything done, and any initial work will be Linux-specific (I
honestly don't care about Mac OS X or Windows).


Nor me, really.

Nevertheless, I've found using PyGTK means that my GUIs run on 
Mac/Windows provided the users are able to install the command line 
packages that they're wrappers for (where that's necessary).  I will 
admit that I had to do a very small bit of Windows specific code to 
properly run CLI commands and capture their output (20 or 30 lines).



If anything does get
done, I'll definitely come back here to get help on the design. I'm
willing to do some leg-work, but I'm not experienced in any way, shape
or form with GUI development (most of my work is server-type stuff in Go
or front-end stuff in JS/HTML5/CSS3).

If we're generally in agreement that a UI toolkit is a good direction,
I'd love to waste the next few months of my life doing something that
likely won't go anywhere. I personally think it's much more exciting to
make something in native D instead of trying to work around the lack of
concern other C++ toolkits like Qt have for cross-language portability.


Yes, if D aspires to be a systems programming language it can't keep 
relying on wrappers around C/C++ libraries (especially C++).  In the 
long term, it should be D all the way down to the OS API.


Peter

Re: Ideal D GUI Toolkit

[Peter Williams]

On 21/05/13 12:53, Adam Wilson wrote:

On Mon, 20 May 2013 16:50:47 -0700, Peter Williams
 wrote:


On 21/05/13 08:49, Adam Wilson wrote:


I'd be willing to lead the project, I'm just not sure I am the right
person to do so. I have a vision, and the skeleton of a design, but no
code. I am willing, but my ability is a question mark...



I'd volunteer to be a foot soldier on this project as I'd like D to
have a useful GUI capability.  At the moment, my experience of GUI
programming is at the user of the API end of the spectrum (mostly
using PyGTK to write GUI wrappers for command line programs to make my
life easier) but I think I'm a quick learner.  Also as a GUI API user
I have some idea of the sorts of thing that make a good API.

If D had a usable GUI API I would port at least one of my current
PyGTK programs to D as it would benefit from better number crunching
capability than Python possesses.

So, if this gets up, give me a call.
Peter



I'd love to get this up and running but I think we've got a blocker
right now in D and that is the lack of package import,
the GUI system is
going to be a monster no matter how it's sliced and I'd lack to avoid
the std.datetime effect. Sorry Jonathan Davis!


Why do you need package import?  Can't you achieve the equivalent by 
having one module that imports all the others publicly leaving the 
application programmer only one module to import?




Once we get package import into D we can start building out the basics.
Do you have any experience with concurrent hashmaps by chance?


No. Why do you want concurrency? Aren't associative arrays hashmaps?  My 
only experience with hashing techniques (other than as an end user of 
classes/functions/features using them) was implementing git binary 
patches in Python for use in one of my GUIs.



Or any
other types of containers?



I implemented a "left leaning red black" tree in Go (as a basis for 
implementing various "set" containers) a while back before I abandoned 
Go due to their silly "inject ';' at the end of lines" hack in the 
lexical analyser.  Also, the basis of my PhD thesis was the equivalent 
of an optimal redundant discrimination tree which is a kind of container 
albeit fairly specialised.


Peter

Re: Ideal D GUI Toolkit

[Peter Williams]

On 21/05/13 08:49, Adam Wilson wrote:


I'd be willing to lead the project, I'm just not sure I am the right
person to do so. I have a vision, and the skeleton of a design, but no
code. I am willing, but my ability is a question mark...



I'd volunteer to be a foot soldier on this project as I'd like D to have 
a useful GUI capability.  At the moment, my experience of GUI 
programming is at the user of the API end of the spectrum (mostly using 
PyGTK to write GUI wrappers for command line programs to make my life 
easier) but I think I'm a quick learner.  Also as a GUI API user I have 
some idea of the sorts of thing that make a good API.


If D had a usable GUI API I would port at least one of my current PyGTK 
programs to D as it would benefit from better number crunching 
capability than Python possesses.


So, if this gets up, give me a call.
Peter

Enhanced LALR(1) Parser Generator for D

[Peter Williams]

As an exercise to help me learn D, I've implemented an enhanced version 
of the LALR(1) parser generator described in Aho, Sethi and Ullman's 
dragon book.  The enhancements include:


1. a built in lexical analyser (where a flex like pattern is required as 
part of the definition of a token),


2. the ability to resolve reduce/reduce conflicts using predicates 
attached to grammar rules (inspired by the work of Ganapathi and Fischer 
in the 80s), and


3. for "literal" tokens the option of using the literal pattern in 
grammar rules instead of the token name e.g. if you had a token named 
LESSOREQUAL with the pattern "<=" then you can "<=" in grammar rules 
instead of LESSOREQUAL.


The code for this tool resides in the dunnart repository at GitHub.

Unfortunately, at this stage, the documentation is not very good but a 
small example that illustrates all features is attached.


As I said at the start, this was an exercise in learning D so there may 
be room for improvement in some of the code.  Suggestions are welcome.


Cheers
Peter
%{
import std.stdio;
double[string] variables;
enum Errors { undefinedVariables = 1, divideByZero = 2, syntaxError = 3 };
uint errors;

void report_errors()
{
auto report = "Errors:";
if (errors & Errors.undefinedVariables) {
report ~= " \"Undefined Variables\"";
}
if (errors & Errors.divideByZero) {
report ~= " \"Divide by Zero\"";
}
if (errors & Errors.syntaxError) {
report ~= " \"Syntax Errors\"";
}
stderr.writeln(report);
}
%}

%field  double value
%field  string id

%token  EOL (\n)
%token  PLUS"+"
%token  MINUS   "-"
%token  TIMES   "*"
%token  DIVIDE  "/"
%token  ASSIGN  "="
%token   NUMBER  ([0-9]+(\.[0-9]+){0,1})
%token  ID  ([a-zA-Z]+)
%token  LPR "("
%token  RPR ")"

%skip   ([\t\r ]+)

%right  UMINUS
%left   TIMES DIVIDE
%left   PLUS MINUS
%left   EOL

%%
line: setup expr ?(errors > 0?) !{report_errors();!}
| setup expr !{writeln($2.value);!}
| setup ID "=" expr ?(errors == 0?) !{variables[$2.id] = $4.value;!}
| setup ID "=" expr !{report_errors();!}
| line EOL line
| line EOL
.

setup: !{errors = 0;!}.

expr: expr "+" expr ?($1.value == 0?) !{$$.value = $3.value;!}
| expr "+" expr ?($3.value == 0?) !{$$.value = $1.value;!}
| expr "+" expr !{$$.value = $1.value + $3.value;!}
| expr "-" expr ?($1.value == 0?) !{$$.value = -$3.value;!}
| expr "-" expr ?($3.value == 0?) !{$$.value = $1.value;!}
| expr "-" expr !{$$.value = $1.value - $3.value;!}
| expr "*" expr ?($1.value == 0 || $3.value == 0?) !{$$.value = -$3.value;!}
| expr "*" expr ?($1.value == 1?) !{$$.value = $3.value;!}
| expr "*" expr ?($3.value == 1?) !{$$.value = $1.value;!}
| expr "*" expr !{$$.value = $1.value * $3.value;!}
| expr "/" expr ?($3.value == 1?) !{$$.value = $1.value;!}
| expr "/" expr ?($3.value == 0?) !{errors |= Errors.divideByZero;!}
| expr "/" expr ?($1.value == 0?) !{$$.value = 0;!}
| expr "/" expr !{$$.value = $1.value / $3.value;!}
| "(" expr ")" !{$$.value = $2.value;!}
| "-" expr %prec UMINUS !{$$.value = $2.value;!}
| NUMBER !{$$.value = $1.value;!}
| ID ?($1.id in variables?) !{$$.value = variables[$1.id];!}
| ID !{errors |= Errors.undefinedVariables; $$.value = 0;!}
| %error !{errors |= Errors.syntaxError;!}
.

Re: Why are opEquals/opCmp arguments not in or const for Objects?

[Peter Williams]

On 19/03/13 15:38, Jonathan M Davis wrote:

On Tuesday, March 19, 2013 02:17:28 Peter Williams wrote:

Am I right in thinking that removal of these methods from Object
will mean that it will no longer be necessary for the the
argument to be of type Object and that the need for casting in
the implementation will go away?


Well, IIRC, if when you override a function, and you give it a different
parameter type, it's a new overload rather than actually overriding anything
(even if the type of the parameter in the derived type's function is a derived
type of the type of the parameter in the base class' function). So, if you
don't use a common type for the parameter, you'll run into overload conflicts
regardless. So, while you _could_ use something other than Object, you could
run into overload conflicts if you do. That can be gotten around by aliasing
base class functions into the scope of the derived class (though that may
cause derived types to be compared as base types if they're referred to via
references to the base type, so that may no be a good idea) or by creating
overloads for comparing every base class, but it's arguably easier to just
accept Object and cast - or accept whatever the base type is which first
introduces opEquals into the hierarchy.

So, there's a good chance that what you'll end up doing is using the base type
in the hierarchy which introduces opEquals as the parameter for opEquals. This
is better than using Object in that it'll avoid having completely unrelated
types even be comparable (as their opEquals wouldn't accept each other), but
it would still require derived types to use that type as the parameter type
for opEquals for the reasons mentioned above.

- Jonathan M Davis



Yes.  I didn't mean to imply that all casting would go away just the 
OBLIGATORY casting of Object.


Peter
PS I'd like to say that this is the first disappointment I've 
encountered in my mission to learn D.  Otherwise, I'm finding it a 
pleasure to use and find the compiler error messages very useful 
compared to those I'm used to with similar languages. Well done!!

Re: Why are opEquals/opCmp arguments not in or const for Objects?

[Peter Williams]

On Monday, 18 March 2013 at 01:05:25 UTC, Jonathan M Davis wrote:

On Monday, March 18, 2013 00:53:52 Stewart Gordon wrote:
Why would some class want to implement these methods in a way 
that alters

the object?


Because const in D is physical const, not logical const. So, 
for instance,
const prevents caching. And it's quite possible that a type 
which really cared
about efficiency would cache the calculated value for toHash. 
Make toHash const
would make that impossible. Another possible problem would be 
lazy
initialization. If opEquals is const, then lazy initialization 
becomes

impossible.

We've discussed this on a number of occasions, and it's clear 
that forcing
these functions to be const is a major problem, and yet they do 
need to be
const for them to work with const objects. What was finally 
decided during the
last big discussion on this a few months back was that we would 
remove
opEqulas, opCmp, toHash, and toString from Object. They don't 
need to be
there. As long as everything in the runtime which deals with 
them is
templated, then there's no technical reason why Object would 
need them. D
isn't Java where we have containers of Object or anything like 
that. Putting

them on Object just restricts us.

So, once all of those functions are removed from Object, 
derived types can
then define them with whatever attributes they want. The only 
thing you lose is
the ability to compare Objects directly, which is not necessary 
in D and is

arguably a bad idea anyway.

The work on this conversion hasn't been done yet, and a 
transition plan will
have to be put in place to minimize code breakage, but that's 
what was decided
on as the solution to the issues with const and Object's 
functions.


- Jonathan M Davis


Am I right in thinking that removal of these methods from Object 
will mean that it will no longer be necessary for the the 
argument to be of type Object and that the need for casting in 
the implementation will go away?


Peter

Re: Why are opEquals/opCmp arguments not in or const for Objects?

[Peter Williams]

On Monday, 18 March 2013 at 00:16:17 UTC, Timon Gehr wrote:

On 03/18/2013 12:19 AM, Peter Williams wrote:

The current signatures for opCmp/opEqual mean that code like:


bool strictly_ordered(T)(in T[] list) {
for (auto j = 1; j < list.length; j++) {
if (list[j - 1] >= list[j])
return false;
}
return true;
}

will fail to compile if T is a class because opCmp cannot be 
called with
a const argument.  This restricts the quality of code that can 
be

written by limiting legitimate use of in/const arguments to
functions/methods.

Trying to work around this problem by defining opCmp/opEquals 
for the
class being used with in or const argument does not work as 
they are not

recognised as an override of the Object methods.



Yes they are.

So my question is "Why are the arguments to opEquals and opCmp 
(for

Objects) not declared in or const?".



Because not all valid implementations can be.


Can't those (rare) implementations just do a non constant cast 
when they cast Object to their desired class?



They shouldn't be in Object anyway.


Yes, if they could just be declared without overriding the 
problem would go away but whichever solution is chosen existing 
code would need minor changes.


Peter

Re: Why are opEquals/opCmp arguments not in or const for Objects?

[Peter Williams]

On Monday, 18 March 2013 at 00:46:46 UTC, Stewart Gordon wrote:

On 17/03/2013 23:19, Peter Williams wrote:

So my question is "Why are the arguments to opEquals and opCmp 
(for Objects) not declared

in or const?".


Known bug.

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



I did look in bugs but failed to find this.

Thanks for the reference.
Peter

Why are opEquals/opCmp arguments not in or const for Objects?

[Peter Williams]

The current signatures for opCmp/opEqual mean that code like:


bool strictly_ordered(T)(in T[] list) {
for (auto j = 1; j < list.length; j++) {
if (list[j - 1] >= list[j])
return false;
}
return true;
}

will fail to compile if T is a class because opCmp cannot be 
called with a const argument.  This restricts the quality of code 
that can be written by limiting legitimate use of in/const 
arguments to functions/methods.


Trying to work around this problem by defining opCmp/opEquals for 
the class being used with in or const argument does not work as 
they are not recognised as an override of the Object methods.


So my question is "Why are the arguments to opEquals and opCmp 
(for Objects) not declared in or const?".


Thanks
Peter