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

Lionello Lunesu wrote:
> 
> "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?

We know what the type of the out argument is. The problem with return value overloading is not knowing what the type should be.


> Can't the compiler treat a return value as an implicit out argument?

Suppose the return value is used as an argument to another function with overloaded versions. Rinse, repeat. The combinations grow out of control.

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.

"e-t172" wrote
> Lionello Lunesu a écrit :
>>
>> "Walter Bright" wrote in message
>>> 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.

Yes, one that is solved like any other that has ambiguity: casting.  We will have the same problem when opImplicitCast is introduced.

This seems like a rare case anyways, not a reason not to have overloaded return values.

-Steve

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


Sean

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

Walter Bright wrote:

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

Ah! As in compare & exchange (cmpxchg & cmpxchg8b) x86 opcodes. I wasn't thinking at the m/code level.

Cheers, b.

-- 

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.

Cheers, b.
-- 

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

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

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

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.

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

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.

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.

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.

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.








-- 

>A stable, even if philosophically distasteful, implementation of the staples is better than a philosophically desirable but
>whimsically changing one.
.
I of course meant Tango.


--