April 29, 2008
Janice Caron wrote:
> 2008/4/28 Simen Kjaeraas <simen.kjaras@gmail.com>:
>>  int main(string[] args)
>>  {
>>   char[] a = cast(char[])args[0];
>>   a[2..5] = "XXX";
>>   writefln(a);
>>   return 0;
>>  }
>>  This compiles and runs, and seems to do what you describe. Sure, there's a
>>  cast there, but it's not all that bad, is it?
> 
> Yes, it's extremely bad. Casting away invariant is UNDEFINED BEHAVIOR,
> and should never be done.
> 

It's not merely undefined, it's *illegal*!
I hate the C/C++ tradition of calling "undefined behavior" to things that are *illegal*. Yes, illegal behavior causes undefined behavior, but they're not the same thing. Illegal is something that may cause your program to crash, or simply become in a fault and erroneous state. Undefined is just undefined. For example, this expression in C:
  a = (x++) + x*2;
has undefined behavior (because of order of evaluation issues). But it's not *illegal* behavior, your program will not crash and burn because of that.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
April 29, 2008
Me Here wrote:
> That, for example, does not mean simply substituting an object handle
> for an OS handle. Nor caching of derived values unless their
> derivation is truly expensive. Nor the use of getters and setters to
> avoid direct manipulation of attributes, unless there is some genuine
> value-add from doing so. OO-dogma that they will isolate the library
> from speculative future changes in the underlying OS calls (that have
> been fixed in stone for 1 or4 decades or more) do not cut much ice
> with me.

I'm of the same opinion with that.

> One of the things that force me to go away from D a couple of years
> ago was the ever changing state of the libraries. Not the internal,
> implementations or occasional bugs, but the constantly changing
> interface definitions.

That's why D 1.0 was split off. It was done to provide a stable platform that only gets bug fixes.
April 29, 2008
Walter Bright wrote:

>Me Here wrote:
>>That, for example, does not mean simply substituting an object handle
>>for an OS handle. Nor caching of derived values unless their
>>derivation is truly expensive. Nor the use of getters and setters to
>>avoid direct manipulation of attributes, unless there is some genuine
>>value-add from doing so. OO-dogma that they will isolate the library
>>from speculative future changes in the underlying OS calls (that have
>>been fixed in stone for 1 or4 decades or more) do not cut much ice
>>with me.
>
>I'm of the same opinion with that.
>
>>One of the things that force me to go away from D a couple of years
>>ago was the ever changing state of the libraries. Not the internal,
>>implementations or occasional bugs, but the constantly changing
>>interface definitions.
>
>That's why D 1.0 was split off. It was done to provide a stable platform that only gets bug fixes.

Understood, but when I went to upgrade from my very old 1.x version and discovered there was a D2,
I did look for an explaination (on the web sote rather than in the forums) and came up short.

I guess the clue was in the alpha status, but a few lines somewhere on the download page explaining the
difference wouldn't go amiss.

As I also mentioned, the descriptions I found (whilst looking for the above) of the new D2 language features
drew me to it. Without thinking the the implications, it strikes me that a segregation of the compilers from
the runtimes would allow the mating of the d2 compiler with the D1 libraries?

The D1 libraries themselves would not use or benefit from the new D2 language features but it would allow
applications access to those features whilst retaining the stability of D1 libraries.

But that probably entails extra work, as well as a not inconsiderable amount of careful consideration
regarding the long term implications, so don't take it as a request. Just a notion in passing.

Anyway, I did promise to get outta yer hair, so...I'm gone.

Thanks again, b.

-- 

April 29, 2008
Walter Bright wrote:
> Steven Schveighoffer wrote:
>> I agree that immutable strings can be valuable.  That's why I think it's important to have a version of toupper that uses invariant strings because you can make more assumptions about when to make copies.  But why shouldn't there be a version that does the same thing with mutable or const strings? Why should a developer be forced to always use invariant strings when the optimizations and multithreading benefits that come with only using invariant strings may not be more important for a particular program than being able to modify a string?  I should still be able to use toupper on mutable strings as well...
> 
> That's why I agreed with Janice on making a stringbuffer module that operates on mutable strings. It's easier than arguing about it, and it doesn't hurt to have such a package. And I suspect that after using it for a while, people will naturally evolve towards using all invariant strings.

"people will naturally evolve towards using all invariant strings."
Oh please. This whole discussion between "Me here" and Walter was always occurring under the notion that one either has to use all mutable strings, or all invariant strings, which is a silly idea. Use what is right for what you are trying to do!

The original post code was a clear-cut example of invariant misuse. If you are going to make one or several different mutations to a string, do not use invariant, use mutable. The fact that there isn't a mutable/in-place tolower has no bearing on the const/invariant system (only on the Phobos library design). So if you had any quarrel, it wasn't with D's immutability system, but with library design (which Walter already said he plans to fix... at least on what std.string is concerned).

And Walter, people won't "naturally evolve towards using all invariant strings" (nor they should). If I have a function where I'm going to perform a series of changes to a string, I'm not going to dup them with each change just to say "How cute, I'm using invariant all the way!". I'll do all the changes on a mutable string, and they return either a mutable, const, or invariant string, as appropriate to what makes sense in the code.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
April 29, 2008
== Quote from Me Here (p9e883002@sneakemail.com)'s article
> Sean Kelly wrote:
> > == Quote from Walter Bright (newshound1@digitalmars.com)'s article
> > > Me Here wrote:
> > > > If that describes copy-swap then yes. Else no :)
> > > copy-swap is what lock free algorithms rely on for updating a data structure. It's at the root of STM, and even has its own TLA, CAS (Copy And Swap).
> >
> > I believe CAS actually stands for "compare and swap" or "compare and set"
> > depending on who you talk to.  RCU is probably a more popular algorithm
> > for copy and swap--it's used in the Linux kernel quite a bit.  It stands for
> > "read, copy, update," I believe.
> >
> >
> > Sean
> From the litrature I found, CAS is (was originally) the name of the opcode
> used on a Sun microprocessor to conditionally and atomically swap the contents
> of two words of memory (or maybe memory and register).
> It also mentions a CASX opcode, and a LL/SC (Load Linked / Store
> Conditional) pairing that can be used as alternatives.

Yeah, LL/SC is pretty cool.  The hardware transactional memory proposals I've seen are like LL/SC on steroids.  Bit more flexible than CAS, but either works.


Sean
April 30, 2008
== Quote from Me Here (p9e883002@sneakemail.com)'s article
> Sean Kelly wrote:
> > == Quote from Me Here (p9e883002@sneakemail.com)'s article
> > > Phobos vs. Tango
> > > I definitely don't want the dead weight of pointless OO wrappers or deeply
> > > nested hierarchies. Nor the "everything must be OO" philosophy.
> > > Once I regain access to std.string for my char[]s, (and a simple,
> > > expectation conformant rand() function :), I'll be happy.
> >
> > Please don't discount Tango based on what has been said about it in this
> > forum.  I know for a fact that Walter, for example, has never even looked
> > at Tango (or he hadn't as of a few weeks ago anyway).  In truth, the percentage
> > of classes to functions in Tango is roughly the same as in Phobos... Tango is
> > just a much larger library.  If you're interested in algorithms and string operations,
> > I suggest looking at tango.core.Array and tango.text.*.  The former is basically
> > C++'s <algorithm> retooled for D arrays, and the latter holds all the string-specific
> > routines in Tango.
> >
> The primary basis of my immediate decision regarding Tango was it incompatibility
> with Phobos as outlined in
>     http://www.d-riven.com/index.cgi?tango-phobos
> (And several other first page hits when googling for "D Tango Phobos")

For what it's worth, the "Tangobos" project is a port of Phobos to the Tango runtime, and a pre-packaged version is available on the Tango website.  If you compare the source code with Phobos itself, you'll find that there are precious few diffs anywhere in the entire package, and the few that exist are mostly in std.thread.  So this may be an option if you'd like to use both together.

> Beyond that, I'm in favour of OO when only when it truly benefits me. That is,
> when it manages state that I would otherwise *have* to manage myself.
> That, for example, does not mean simply substituting an object handle for an OS handle.
> Nor caching of derived values unless their derivation is truly expensive.
> Nor the use of getters and setters to avoid direct manipulation of attributes,
> unless there is some genuine value-add from doing so.

That's the basic philosophy behind Tango.  In fact, the bulk of the objects in Tango are in the IO package, with much of the remainder being in places where polymorphism is desirable (localization, for example).  If you find an object in Tango that has no actual state information, it's generally packages as a class for this reason.

> OO-dogma that they will isolate the library from speculative future changes in the
> underlying OS calls (that have been fixed in stone for 1 or4 decades or more)
> do not cut much ice with me.

Me either.  However, since Tango is portable across Win32 and Posix systems (currently), I do think an argument could be made for some level of abstraction.  But the C API headers are available as well if you really want to use them.

> I'm also not fond of all-in-one library packaging. Seems to me that there is enough information in the source code to allow libraries to be packaged as discrete dlls/sos and to only statically link against those required. But that may be a tool chain problem rather than anything to do with Tango.

This was actually driven by fairly vocal user request.  The original conception was for Tango
to be a lightweight, modular framework to be extended by users rather than a monolithic
library.  In fact, we didn't even distribute an all-in-one prebuilt library for Tango until
sometime last summer.  Before that we expected that a tool such as Bud or Rebuild would
be used.  This is still quite possible however, and the modular design in terms of code
dependency is still in place.  If you choose to toss the tango-user lib altogether and find
you want even more modularity, I suggest looking at this page:

http://dsource.org/projects/tango/wiki/TopicAdvancedConfiguration

As far as I know, I'm the only one that has actually read it so it's a bit out of date (the library
names are wrong), but the basic concept still applies.  That is, the choice of a GC can be made
at link-time with Tango, and other portions of the runtime are easily replaceable as well.  Some
kernel projects have found this useful in the past.

> It should be possible to substitute one implementation of a std.* library for another,
> without it being an all or nothing change. I should be able mix'n'match between
> implementations of std.* packages.
> For example, with the std.string problem I've been having. If I use
>     import std.string;
>     char[] a = readln();
>     a.toupper();
> it should work. If I do
>     import std.string.immutable;
> it wouldn't.

Agreed.  My biggest complaint here is having to maintain two essentially identical packages, assuming I were to do such a thing.  This is why I find Steven's "scoped const" proposal so attractive.

> One of the things that force me to go away from D a couple of years ago was the ever changing state of the
> libraries. Not the internal, implementations or occasional bugs, but the constantly changing interface definitions.
> It becomes impractical to develop a major project when you're constantly rewriting major chunks of code to accommodate
> the latest set of group think on the best way to package the OS and "C lib" functionality.
> Back then, I put it down to the necessary gestation of a new language, and moved away to get my project done.
> I've now come back and find that the same situation exists. The answer to an essentially trivial problem is to write
> and entire new library. Or rather, since the library I need was already a part of Phobos with D 0.-something
> resurrect and old library.
> And that's the most worrying thing of all. The removal of the existing library from Phobos because the main proponents
> suddenly drank the cool aid of Invariant strings--especially for reasoning that I still find entirely specious--does not bode well
> for ongoing stability

The lack of responsiveness of the Phobos maintainers (ie. Walter) is what drove us to create Tango in the first place.  I'll freely admit that the design of Tango has changed here and there as we've moved through beta, but it's largely solidified now and will be frozen once we hit 1.0. Neither I nor the other Tango developers have any desire to maintain deprecated code and the like, so we've been doing our utmost to find a design that we hope will last.  Also, that there is at least one commercial project based on Tango (I think there are actually more, but I don't keep track of this very closely) says a lot about the library's stability and its support.

> I had hoped that during my two years away, that at least the interfaces would have become standardised,
> even if the implementations varied from release to release. But if whole chunks of functionality can suddenly
> disappear from the library, at the same time as major new chunks of very desirable functionality are added to the language,
> on the whim of 1 or 4 major players getting religion, then I'm really not sure that D is, or will ever be,
> ready for anything other than academic exploration of compiler technology.

To be honest, I actually feel much the same.  However, I also feel that D 1.0 is a fantastically
designed language overall, and I would choose it in a second over C or C++ (I'm a systems
programmer so those are really the only other choices available).  So at the end of the day, I
will be disappointed of the "future of D" takes a hard left-hand turn towards somewhere
I have no interest in going, but since I'm really quite happy with D 1.0 I won't shed too many
tears over it.  This perhaps doesn't bode terribly well for my use of D in the long-term, but
that's a bridge I'll jump off if and when I come to it.

> Reading that back. the independence of Tango begins to be more attractive, even if I have a distaste for the
> "everything must be OO" philosophy that (apparently) underlies it. Maybe I'll pull a copy and look for myself.
> For my current needs, I'm just looking for C speed with having to manage my own memory
> For the project I went away from D for 2 years ago, and came back hoping for stability, my own personal
> research project come memorial folly to be, I don't think D is yet ready for that. Maybe D1 if it doesn't
> becomes completely unsupported.

If it's speed you're looking for, Tango is it ;-)  The IO subsystem trounces pretty much everything
I've seen it compared to, for example.  In practice, I think you'll find that one reason for this is that
no hidden allocations take place anywhere in Tango.  This tends to conflict with convenient use in
some cases for simple apps however, so as things stand now I do think that some users would
benefit from convenience wrappers.  I tend to do this sort of thing myself for my own projects,
but a third-party package would be nice for those less inclined.  If you're interested in direct
performance comparisons however, I suggest reading the "benchmarks" links on this page:

http://dsource.org/projects/tango/wiki/Documentation

The XML tests in particular are pretty astounding (I feel comfortable saying that because I had nothing to do with the development of that particular package :).

> In the interim I've "done the rounds" of an amazing variety of languages. From the functional brigade,
> Haskell, OCaml, Mozart/Oz, Erlang  et al. and various of the newer dynamic languages. They all have their
> attractions, but most are spoilt by some level of dogma. Haskell with is purity. Python with the whole
> significant whitespace thing. P6 with unix-first, and non-delivery.
> Mostly, the dynamics lack the low-level control and performance I need. I've been seriously working with
> structured assembler to achieve the low level control and performance I want, but doing everything yourself
> just takes you off into far to many interesting side projects. Implementing your own memory management
> could occupy a lifetime; especially if you consider the possibility and advantages of using (wait for it) a
> segmented architecture. Most older programmers memory of segmented memory stems from the 16-bit Intel
> days and they (almost) universally eschew any notions of it now a 32-bit (and 64-bit) flat memory models are available.
> But there are some very interesting possibilities in combining 32-bit segments and virtual memory.
> D is my last best hope of avoiding the assembler route and trying to do it all myself. Walter's pragmatism stood out
> in my early experience of both the language and library design--al be it that they kept changing;)--but I was really
> expecting (hoping) for greater stability by this point.

Personally, the combination I find most attractive for my work right now is Erlang backed by C or D for the performance-critical work.  That gives me the easy parallelization I want, IPC, etc, plus an easy way of optimizing the heck out of trouble spots... or simply sidestepping the strict functional model when data sharing is actually needed.  I've actually come to feel that having a language separation here is a good thing as well, because it prevents "bleed through" of concepts which I feel risks poisoning the efficacy of each approach.

As for the rest, Kris, one of other Tango developers, has done a lot of work in the embedded space and
pushed very hard in the past for D to better support this style of programming.  He wasn't terribly successful
insofar as language/compiler development was concerned (there has been a lot of talk in the past about TypeInfo
in particular), but Tango, at least, was designed with embedded development in mind.  The lack of hidden DMA,
for example.  I can't say whether Tango will suit your needs, but it does seem to at least match your general
goals with D.

> Ooh. Did I write all that? Still. It has persuaded me to at least go look at Phobos, even if it is done with a jaundiced eye.
> A stable, even if philosophically distasteful, implementation of the staples is better than a philosophically desirable but
> whimsically changing one.
> Cheers for prompting me to re-think my blanket dismissal. b.

Thank you for reconsidering :-)  D may be a young language, but there has really been quite a bit of drama surrounding it in newsgroup discussion.  I think it can sometimes be difficult to look past all this and take the time to decide for oneself.  If nothing else, doing so takes time, and even I tend to employ the "30 second rule" when it comes to new technology.


Sean
April 30, 2008
== Quote from Me Here (p9e883002@sneakemail.com)'s article
> As I also mentioned, the descriptions I found (whilst looking for the
> above) of the new D2 language features
> drew me to it. Without thinking the the implications, it strikes me that a
> segregation of the compilers from
> the runtimes would allow the mating of the d2 compiler with the D1
> libraries?

See Tango, once again ;-)  In fact, as things stand, the same runtime could
be used for both 1.0 and 2.0 with a bit of work.  I haven't done this with
Tango mostly because I lack the time, but it's quite possible.  Alternately,
separate runtimes could be distributed and linked individually without
pulling in the bulk of an entire standard library.  The "Advanced
Configuration Guide" I liked previously for Tango shows how to do it.
This is simply more flexibility than the typical user cares about or wants
to deal with, so the sub-libraries are repackaged into a larger aggregate
library for the default distribution.  But if you build Tango locally you'll
find that the sub-libraries are still built behind the scenes.  From memory,
the names are:

libtango-rt-dmd.a : Tango runtime for DMD
libtango-rt-gdc.a : Tango runtime for GDC
libtango-gc-basic.a : Tango basic/default garbage collector
libtango-cc-tango.a : "common code" for the Tango standard library

The runtime contains only the compiler runtime code, the GC library only the garbage collector, and the "common code" library contains user-facing code which actually needs to be linked into every D application--that being thread code and some error handling routines. If you want to build on a system with no multithreading, for example, simply toss stub out the 3 or so calls that this module exposes.

> The D1 libraries themselves would not use or benefit from the new D2
> language features but it would allow
> applications access to those features whilst retaining the stability of D1
> libraries.

Right.  The greatest obstacle here is the const design, since the meaning of "const" is actually different between D 1.0 and 2.0, as well as the requirement that even code in version blocks must be syntactically correct.  Thus to support a toString method that returns a const string, for example, the return value must be declared as an alias using a string mixin.  Messy stuff, but it does work.


Sean
April 30, 2008
Sean Kelly wrote:
> If it's speed you're looking for, Tango is it ;-)  The IO subsystem trounces pretty much everything
> I've seen it compared to, for example.  In practice, I think you'll find that one reason for this is that
> no hidden allocations take place anywhere in Tango.  This tends to conflict with convenient use in
> some cases for simple apps however, so as things stand now I do think that some users would
> benefit from convenience wrappers.  

Yes please! votes++
I don't need blazing speed for my debug printfs. I need the most convenient API possible. Stdout.print("hi").newline is not quite that.

> I tend to do this sort of thing myself for my own projects,
> but a third-party package would be nice for those less inclined.  

I don't know why, but I just really dislike seeing little "mytools" dependencies dangling off of what would otherwise be nice little self-contained modules.  Maybe I just find it makes it harder to reuse code.  This module depends on "mytools" but over there we're using "yourtools".  Do we merge them to become "ourtools", or keep both, or port my code to use yourtools instead?  It's just easier to mix and match if a module doesn't have such frivolous external dependencies.

--bb
April 30, 2008
Sean Kelly wrote:

> Right.  The greatest obstacle here is the const design, since the meaning
> of "const" is actually different between D 1.0 and 2.0, as well as the
> requirement that even code in version blocks must be syntactically
> correct.  Thus to support a toString method that returns a const string,
> for example, the return value must be declared as an alias using a string
> mixin.  Messy stuff, but it does work.
> 

I personally think that for a big library like Tango, using a preprocessor would be a less painful way to go.  The shipped versions of the lib would have the preprocessor already pre-run, so would be pure D code.

--bb
April 30, 2008
e-t172 wrote:
> Lionello Lunesu a écrit :
>>
>> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:48169E90.6050700@digitalmars.com...
>>> Me Here wrote:
>>>> Janice Caron wrote:
>>>>> Functions don't overload on return value.
>>>> They don't? Why not? Seems like a pretty obvious step to me.
>>>
>>> Type inference in D is done "bottom up". Doing overloading based on function return type is "top down". Trying to get both schemes to coexist is a hard problem.
>>
>> But a function's result can be overloaded using "out", so why can't it be overloaded using the return value?
>>
>> Can't the compiler treat a return value as an implicit out argument?
> 
> Consider this:
> 
> int foo();
> float foo();
> 
> void bar(int a);
> void bar(float a);
> 
> Then this:
> 
> void main()
> {
>     bar(foo());
> }
> 
> There is an obvious problem here.

One of two things, make an assumption as to which is called by which has the higher priority(based on precision or type). Or throw a compiler error if no cast is made.

Overload Ambiguity, Cast Must be made when both return overload and parameter overload types are ambigious.
1 2 3 4 5 6 7
Next ›   Last »