Recently I was bitten by rand from c.stdlib and phobos.random. I meant to call the D version but called stdlib instead.

The problem is that the stdlib version is quite different:

import c.stdio;
import c.stdlib;
import random;

int main (char [][] args)
{
    for(int i=0; i<10; i++) {
       printf("c.stdlib.rand=%u\n",c.stdlib.rand());
    }

    for(int i=0; i<10; i++) {
       printf("random.rand=%u\n",random.rand());
    }
    return 0;
}

====
Output:

c.stdlib.rand=16838
c.stdlib.rand=5758
c.stdlib.rand=10113
c.stdlib.rand=17515
c.stdlib.rand=31051
c.stdlib.rand=5627
c.stdlib.rand=23010
c.stdlib.rand=7419
c.stdlib.rand=16212
c.stdlib.rand=4086
random.rand=2329848284
random.rand=966896356
random.rand=2223890246
random.rand=3572420830
random.rand=2088501916
random.rand=4169283756
random.rand=1218664906
random.rand=125222921
random.rand=1576103088
random.rand=4163571171

====

I think that there should be no D functions named identically. It will only result in confusion or code drawn into a project from different sources for the same purpose. (isdigit, ...)

If they are named identically they should behave identically.

BTW I think that no decent C compiler should have an anachronistic 16-bit generator.

--
Helmut Leitner    leitner@hls.via.at Graz, Austria   www.hls-software.com

Helmut Leitner wrote:
> 
> I think that there should be no D functions named identically. It will only
> result in confusion or code drawn into a project from different sources for
> the same purpose. (isdigit, ...)

I don't think this is a good idea.  Isn't this what the namespaces are for?

Chris

What I'm going to do is (finally) implement the notion of a private import. That should resolve most of this. Also, C's rand behavior is defined by the C spec.

Good.  Does that mean import a module, but *not* what it imports?  Or import
a module but its symbols aren't exported in this module's namespace?
So why does the C spec define it to have 16 bits?

Sean

"Walter" <walter@digitalmars.com> wrote in message news:b99f9b$phh$2@digitaldaemon.com...
> What I'm going to do is (finally) implement the notion of a private
import.
> That should resolve most of this. Also, C's rand behavior is defined by
the
> C spec.

Walter wrote:
> ...
> Also, C's rand behavior is defined by the C spec.

No.

The standard (C99, but I don't think anything changed) says:

  The rand function computes a sequence of pseudo-random integers
  in the range of 0 to RAND_MAX.

  RAND_MAX is at least 32767.

  ...

There is an *example* that has been considered harmfulby those that actually use random numbers:

  int rand(void) {
     next = next * 1103515245 + 12345;
     return (unsigned int) (next/65536)%32768;
  }

because it has such a low quality.

No compiler builder is bound to this example and actually only a few have used it. E. g. Borland C provides a 32-bit rand that passes the typical statistical tests without problems.

It is really easy to do because many good generators are available.

It is a quality of implementation issue.

--
Helmut Leitner    leitner@hls.via.at Graz, Austria   www.hls-software.com

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:b9a3o0$1ehc$1@digitaldaemon.com...
> Good.  Does that mean import a module, but *not* what it imports?

Yes.

>  Or import
> a module but its symbols aren't exported in this module's namespace?
> So why does the C spec define it to have 16 bits?

It just solidified legacy practice.

Walter wrote:
> "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message
> news:b9a3o0$1ehc$1@digitaldaemon.com...
> 
>>Good.  Does that mean import a module, but *not* what it imports?
> 
> Yes.

Is it quite a safe practice?

I mean, maybe if a module imports another one, it may also also export symbols which rely on that import? Like, struct definition which includes a struct from an imported module would become unusable in another module?

Is it possible to just make an import inside a private section, which would mean that this imported module is not exported, but only available to the implementation of the module and does not make a part of its interface?

What syntax/semantics are you thinking of right now?

>>So why does the C spec define it to have 16 bits
> 
> It just solidified legacy practice.

My Speccy 48 also had a 16-bit random. :>

-i.

No, the struct imported would be usable, as *it* has the imports visible. By the time you use it, it's already defined fully.  But the user of the struct could not also automatically use the contents of the imported module used to build the struct, but only the stuff in the module containing the struct itself.

I suppose template name lookup could be tricky for this.

Sean

"Ilya Minkov" <midiclub@8ung.at> wrote in message news:b9gp14$oo2$1@digitaldaemon.com...
> Walter wrote:
> > "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:b9a3o0$1ehc$1@digitaldaemon.com...
> >
> >>Good.  Does that mean import a module, but *not* what it imports?
> >
> > Yes.
>
> Is it quite a safe practice?
>
> I mean, maybe if a module imports another one, it may also also export symbols which rely on that import? Like, struct definition which includes a struct from an imported module would become unusable in another module?
>
> Is it possible to just make an import inside a private section, which would mean that this imported module is not exported, but only available to the implementation of the module and does not make a part of its interface?
>
> What syntax/semantics are you thinking of right now?
>
> >>So why does the C spec define it to have 16 bits
> >
> > It just solidified legacy practice.
>
> My Speccy 48 also had a 16-bit random. :>
>
> -i.

"Sean L. Palmer" <palmer.sean@verizon.net> escribió en el mensaje
news:b9a3o0$1ehc$1@digitaldaemon.com...
| Good.  Does that mean import a module, but *not* what it imports?  Or
import
| a module but its symbols aren't exported in this module's namespace?
| So why does the C spec define it to have 16 bits?
|
| Sean
|

I guess I'd prefer the second one. The thing is that, for example, I can't
import both string and date because dmd says "date.d(351): function toString
conflicts with string.toString at string.d(1438)".
Like someone else said (I can't remember right now), I'd expect that at
least there wouldn't be any conflicts with names inside phobos.

————————————————————————— Carlos Santander


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.478 / Virus Database: 275 - Release Date: 2003-05-06

Carlos Santander B. wrote:
> "Sean L. Palmer" <palmer.sean@verizon.net> escribió en el mensaje
> news:b9a3o0$1ehc$1@digitaldaemon.com...
> | Good.  Does that mean import a module, but *not* what it imports?  Or
> import
> | a module but its symbols aren't exported in this module's namespace?
> | So why does the C spec define it to have 16 bits?
> |
> | Sean
> |
> 
> I guess I'd prefer the second one. The thing is that, for example, I can't
> import both string and date because dmd says "date.d(351): function toString
> conflicts with string.toString at string.d(1438)".
> Like someone else said (I can't remember right now), I'd expect that at
> least there wouldn't be any conflicts with names inside phobos.
> 

I like Python's way of handling imports.  Name conflicts simply aren't an issue.

import mod;

mod.method();      // fine
method();          // No good. You need the module name.

import mod.method; // "from mod import method" in Python
method()           // fine now

import mod.*;      // "from mod import *".  Imports everything into the
                   // current namespace

method();          // also fine

Any conflicts that may arise from importing directly into the current module namespace would be a compile error then and there, not when a conflicted symbol is actually used.