• Dmitry Olshansky (18/18) Oct 31 2013 A small proposal to introduce such a facility into druntime.
• Jakob Ovrum (38/39) Oct 31 2013 I'll move the pseudo-namespace issue here:
• Dicebot (7/8) Oct 31 2013 Very true. I sincerely believe that at some point guideline

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

A small proposal to introduce such a facility into druntime.

See PR for preliminary API:
https://github.com/D-Programming-Language/druntime/pull/653

In focus is to provide a unified API that allows the most common 
scenarios to work efficiently:
  - allocating memory that has executable permissions
  - reserve and commit memory pages gradually
  - (un)locking of memory in physical RAM
  - getting the OS page size

And another one case I haven't yet found a way to implement/use portably:
  - guard pages

Platforms diverge significantly enough that there is not even a remote 
chance to have 100% efficient wrapper for all potential uses cases. But 
most of them should be possible with a bit of overhead.

Same reservations apply to any attempt to accommodate for each 
platform's special tricks (they are simply not portable).

-- 
Dmitry Olshansky

"Jakob Ovrum" <jakobovrum gmail.com> writes:

On Thursday, 31 October 2013 at 18:07:07 UTC, Dmitry Olshansky 
wrote:
 A small proposal to introduce such a facility into druntime.

I'll move the pseudo-namespace issue here:

Currently it uses a struct `VMM` where all members are static as 
a namespace, much like `core.memory.GC`. However, IIRC, this 
practice has since been discussed at length, and I think the 
consensus has consistently been that it is generally a bad idea, 
and that it should be avoided for new code.

The obvious argument for using a pseudo-namespace is that the 
symbols would be too prone to collision or ambiguity if they were 
module-level. Indeed the names at hand are arguably very generic, 
examples including "allocate", "free" and "reserve".

However, the problem statement assumes that the module is 
imported plainly as `import core.vmm;` at module-level scope. The 
issue can be resolved flexibly by using other import forms, such 
as renamed or selective imports, and/or by using scoped imports.

At module-level it could be `import vmm = core.vmm;`, and when 
scoped it could be just `import core.vmm;` or `import core.vmm : 
allocate, free;`, eliminating the ambiguity, both for the 
compiler and the programmer. Of course, selective imports can be 
renamed as well, so another solution could be `import vmm : 
vmmAlloc = allocate, vmmFree = free` even in a broader scope such 
as the module-level scope.

I think by using a pseudo-namespace or a fixed name prefix 
(essentially the same thing), the user is locked into one 
solution, but by simply placing them at module-level scope with 
their undecorated names, the client can solve the problem in ways 
that best fit the client code.

I think names such as `std.algorithm.copy/map` and 
`std.file.read/write` is good precedent that shows that D can 
handle these generic, module-level symbol names without creating 
unreadable code, and it should be clear to most of the community 
by now that we have the tools necessary to avoid name collision 
errors.

AFAIK, the `core.memory.GC` struct stems from the Tango tradition 
of using structs as pseudo-namespaces, which I think is a less 
relevant practice now that we have scoped imports and a 
(slightly) less buggy module system.

"Dicebot" <public dicebot.lv> writes:

On Thursday, 31 October 2013 at 18:40:16 UTC, Jakob Ovrum wrote:
 ...

Very true. I sincerely believe that at some point guideline 
"always use scope local imports when possible, with either short 
alias or explicit imported symbol list" will be in every single D 
cookbook. Most trouble with D module system come from habit of 
simply throwing in top-level imports like it was done with C/C++ 
includes.