3 questions regarding modularizing code

[vlad lorenzo]

Hello, new user here.

After browsing the documentation and the forum I still have some doubts regarding the best approach to modularization/isolation of code in order to prevent name clashes or unintended overwrites.

[*]Are the 16 slots for C callbacks global or per shared object?

e.g.: If I load two independent modules that load two unrelated .so but each one registers a callback on the same slot will they overwrite each other?

If this is the case is there any way around it?

[*]In http://www.newlisp.org/downloads/CodePatterns.html#toc-3">Writing software in modules it's suggested to create a context per module.

In the samples the contexts are named withing the modules.

Wouldn't it be more flexible to to let the user of the module manage the name-spaces instead of hard-coding them?

i.e.: not using contexts in the module file and using (load "module.lsp" 'WHATEVER-CTX) in the file that requires the module.

[*] Is there a way to generate anonymous contexts? Is using UUIDs or a global counters the only way to avoid context name clashes?

[/list]

Please feel free to suggest any other strategy if you think I'm approaching this from the wrong angle. I've only used statically scoped languages and I'm trying to get the same level of isolation with newLISP. Dynamic scope doesn't seem to be an issue thanks to letex and expand and in fact it seems to open the the door to new possibilities.

I'm currently having fun with both, newLISP and http://www.software-lab.de/down.html">PicoLisp



Thank you very much,

vlad

[Lutz]

--- Each of the 16 slots can only have 1 callback. The last function symbol to register, has the slot. So, yes they will overwrite each other, no way around this. But reassigning a slot to a different symbol is a very fast operation.



see also:

http://www.newlisp.org/downloads/OpenGL/opengl-demo-lsp.txt">http://www.newlisp.org/downloads/OpenGL ... mo-lsp.txt">http://www.newlisp.org/downloads/OpenGL/opengl-demo-lsp.txt

http://www.newlisp.org/downloads/GTK/DirectGTK.lsp">http://www.newlisp.org/downloads/GTK/DirectGTK.lsp

http://www.newlisp.org/downloads/GTK/fractal.lsp">http://www.newlisp.org/downloads/GTK/fractal.lsp



for real world callback examples.



--- As soon as a symbol is read in, it is created and has its home in a name-space and cannot move from there. And yes:

Code Select Expand

(load "module.lsp" 'WHATEVER-CTX)

is a possibility. In this case "module.lsp" would not contain a a context statement at the beginning. It would then be compiled into 'WHATEVER-CTX.



--- There are no anonymous contexts.



My recommendations would be to follow the patterns as outlined in:



http://www.newlisp.org/downloads/CodePatterns.html#toc-3">http://www.newlisp.org/downloads/CodePa ... html#toc-3">http://www.newlisp.org/downloads/CodePatterns.html#toc-3

and in:

http://www.newlisp.org/downloads/newlisp_manual.html#contexts">http://www.newlisp.org/downloads/newlis ... l#contexts">http://www.newlisp.org/downloads/newlisp_manual.html#contexts



In principle there are two views of contexts (1) as program modules and (2) as dynamic objects in an OO programming sense. Although contexts/name-spaces can be created and deleted during run-time, it is not very efficient.



If you are looking for creation of more dynamic volatile and anonymous objects, look into FOOP:



http://www.newlisp.org/downloads/newlisp_manual.html#foop">http://www.newlisp.org/downloads/newlis ... .html#foop">http://www.newlisp.org/downloads/newlisp_manual.html#foop

Dynamic scope doesn't seem to be an issue thanks to letex and expand and in fact it seems to open the the door to new possibilities.

... yes! and I would add:



Dynamic scope is not an issue, (a) because of contexts/namespaces, and (b) most people are trained to avoid free variables in functions anyway. For those who really understand dynamic scoping, free variables and their dynamic binding into caller functions offer interesting possibilities. See Separations of Concerns and Aspect Oriented Programming.

[vlad lorenzo]

Thank you very much for your answers, I'll go through the links, but above all thank you for releasing newLISP.

I haven't been so impressed with a language since I found FORTH. It's refreshing to see a language embracing dynamism to this extent while remaining compact and approachable.

After being disappointed by static languages (at least in the problem domains that I work in), adding self imposed constraints on top of the constraints mandated by the language I came to the conclusion that it was a dead end. Software either broke in a changing environment or lost its integrity along with any sense of pride that I might had when writing it.

I'm now trying to approach thing from the opposite direction. I don't know where it's going to take me but It has definitely brought back a sense of excitement and discovery.

Thank you.

[itistoday]

I just released a little bit of code that makes modularization real simple and safe like in Java. Check it out:



http://newlispfanclub.alh.net/forum/viewtopic.php?f=2&t=3670">http://newlispfanclub.alh.net/forum/vie ... f=2&t=3670">http://newlispfanclub.alh.net/forum/viewtopic.php?f=2&t=3670

[vlad lorenzo]

Thank you very much for sharing, I'll check it out.



Up to now my impression is that the approach of xml to name-spaces is provably the most effective one:

Using a URL to define a unique global name-space and a symbol that references it as a prefix to cut down on the verbosity.

e.g.: in the module file:

(context 'example.com/library-name/module-name)

; code...

(context)



in the MAIN file:

; since (context) is the las evaluated expression it can be assigned to a symbol

(define xx (load "/home/vlad/newlisp/example.com/library-name/module-name.lsp"))



I thought of creating a library to add more features, but adding another dependency creates a barrier to sharing code.

i.e.: if every developer has his own unique way of managing name-spaces interoperability tends to suffer.

But I'll check out your library before settling on this.



I haven't looked into the other two problems mentioned in my original post:

* avoiding slot clashes when using multiple libraries that use c-callbacks (a global manager is the only solution I can think of so far, but it has the same sort of dependency/sharing drawbacks)

* creating anonymous contexts to pass around as references without name clashes. (I still haven't looking into FOOP, so there might be a solution there)



Again, thank you for sharing.

[itistoday]

Thank you very much for sharing, I'll check it out.



Up to now my impression is that the approach of xml to name-spaces is provably the most effective one:

Using a URL to define a unique global name-space and a symbol that references it as a prefix to cut down on the verbosity.

e.g.: in the module file:

(context 'example.com/library-name/module-name)

; code...

(context)



in the MAIN file:

; since (context) is the las evaluated expression it can be assigned to a symbol

(define xx (load "/home/vlad/newlisp/example.com/library-name/module-name.lsp"))



I thought of creating a library to add more features, but adding another dependency creates a barrier to sharing code.

i.e.: if every developer has his own unique way of managing name-spaces interoperability tends to suffer.

But I'll check out your library before settling on this.

Based on that I think you'll find it suits your needs. :-)

* creating anonymous contexts to pass around as references without name clashes. (I still haven't looking into FOOP, so there might be a solution there)

That's one of the things Objective newLISP can solve (click the link in my signature).