FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

import question / feature request

 
Post new topic   Reply to topic     Forum Index -> MiniD
View previous topic :: View next topic  
Author Message
Ligustah



Joined: 21 Oct 2007
Posts: 45
Location: Berlin, Germany

PostPosted: Tue Nov 06, 2007 6:38 am    Post subject: import question / feature request Reply with quote

Hi,
I have two litte questions:

1.
I was searching for something equivalent to this python statement:
Code:
import from <module name> *

It's the syntax for selective imports (you could replace the * with comma separated names). Is there something like this already in MiniD? DI'd like to have something like this:
Code:
import <module name> : *;

to import all of the functions of that module, as it could be very useful IMHO.

2.
I was woundering that:
Code:
function bar() {}

is the same as:
Code:
local function foo() {}

I thought, that a language that aims to be embedded into other applications , would only create local functions, if you explicitly declared them, as i mostly declare functions to call them from the program later. Is there an important reason for the implicit "local" ?

Mfg Ligustah

Btw: "Mfg" is german. it's just one of my habits to write it and i just noticed it^^
http://dict.leo.org/ende?search=mit+freundlichen+gr%FC%DFen
Back to top
View user's profile Send private message
JarrettBillingsley



Joined: 20 Jun 2006
Posts: 457
Location: Pennsylvania!

PostPosted: Tue Nov 06, 2007 9:28 am    Post subject: Reply with quote

Quote:
It's the syntax for selective imports (you could replace the * with comma separated names). Is there something like this already in MiniD? DI'd like to have something like this: ... to import all of the functions of that module, as it could be very useful IMHO.


There is explicit selective importing which looks like the corresponding D code:

Code:
import foo : one, two, three;


The problem with the "import all" version is that in the above example, 'one', 'two', and 'three' are local variables. Locals are kept on the stack and the number of locals in a function is hard-coded. You can't create a bunch of locals for the "import all" statement, because you don't know how many symbols there will be in the imported module, and so you don't know how many locals to reserve (or what to call them). The alternative would be to import all the other module's symbols into this module's public namespace, but that would be just horrendous: you'd be able to access all of B's members through module A if A imports all of B's members. This could be solved with yet another level of namespacing (module namespace > import namespace > locals), but..

Quote:
I thought, that a language that aims to be embedded into other applications , would only create local functions, if you explicitly declared them, as i mostly declare functions to call them from the program later. Is there an important reason for the implicit "local" ?


It's mostly out of good encapsulation design. You make global only the things you want to be accessible outside the module. It also makes more sense for nested functions to be local by default.

Quote:
Btw: "Mfg" is german. it's just one of my habits to write it and i just noticed it^^


I was wondering about that Wink
Back to top
View user's profile Send private message
Ligustah



Joined: 21 Oct 2007
Posts: 45
Location: Berlin, Germany

PostPosted: Tue Nov 06, 2007 10:56 am    Post subject: Reply with quote

JarrettBillingsley wrote:
This could be solved with yet another level of namespacing (module namespace > import namespace > locals), but..
But? Razz Seriously, I don't really understand the problem Embarassed Where is the big difference between importing three functions and importing maybe 7 or 8 available in the module?

Is that the reason:
JarrettBillingsley wrote:
the number of locals in a function is hard-coded
Does that mean, that there is only a limited number of locals "available"?

JarrettBillingsley wrote:
[...]. It also makes more sense for nested functions to be local by default.
Mh... I see.
Back to top
View user's profile Send private message
JarrettBillingsley



Joined: 20 Jun 2006
Posts: 457
Location: Pennsylvania!

PostPosted: Tue Nov 06, 2007 11:36 pm    Post subject: Reply with quote

Ligustah wrote:
JarrettBillingsley wrote:
This could be solved with yet another level of namespacing (module namespace > import namespace > locals), but..
But? Razz Seriously, I don't really understand the problem Embarassed Where is the big difference between importing three functions and importing maybe 7 or 8 available in the module?

Is that the reason:
JarrettBillingsley wrote:
the number of locals in a function is hard-coded
Does that mean, that there is only a limited number of locals "available"?


In a way, yes. When you do "import foo : a, b" it gets turned into "local a, b; import foo; a = foo.a; b = foo.b;". Those local declarations are in turn turned into what amounts to telling the compiler "reserve the next two available stack slots for some variables." The stack is really nothing but an array and locals are indices into that array. These indices are hard-coded at compile time, meaning you lose any information about which slot corresponds to which variable, and there's no way to "dynamically" allocate locals at runtime -- there are only as many locals in your function as you declare. This makes local accesses much more efficient (~4x faster than in Python), but is a bit less flexible.

This is one instance of where this system presents a problem. Another is when you try to use eval() or loadString(), you'll notice you can't access local variables in the enclosing scope, simply because that information no longer exists in the compiled version of the function. In Python this is easy and is no more complex than setting the parent environment of the eval'ed string to the enclosing function's environment, since locals are kept in a table. Keeping locals in a namespace is bad news for performance.

Solving the import issue by introducing another level of namespacing is tricky and inefficient, for the sake of doing something that's generally considered a bad use of import (ask most seasoned Python and Java users, and they'll tell you that * is bad). Not only does it make creating actual globals harder, but it adds another level of namespace lookup, making things just that much slower. If you reeeeeeeally want to import all the globals from another module into this one's namespace, you could do the following:

Code:
module foo;
import bar;

foreach(k, v; bar)
    foo[k] = v;


Basically, you copy all the globals from the other module into this module's global namespace. As long as you don't mind all those globals then becoming visible from foo, this works fine.
Back to top
View user's profile Send private message
Ligustah



Joined: 21 Oct 2007
Posts: 45
Location: Berlin, Germany

PostPosted: Thu Nov 08, 2007 2:16 pm    Post subject: Reply with quote

Ok. I understand. I think I have to adapt to the selective import then Rolling Eyes

Mfg Ligustah
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> MiniD All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group