Topic: Like the "include" keywords in c language

[Keith™]

What is the big deal with having an include directive in lisp?

The way I see it is you simply load the thing ....

Code: [Select]

(load "required.lsp")

If you want to make it "feel" like C then write a directive function and put it in the acaddoc.lsp ...

Code: [Select]

(defun include (fn)
  (load fn)
)

then in your other lsp files use it like this:

Code: [Select]

(include "this.lsp")

easy peasy

[Kerry]

This is a slightly more robust loader.

Code - Auto/Visual Lisp: [Select]

1. ;;(include <"CommandName"> <"fileName">)
2. ;;
3. (defun include (cmdString fn)
4.    (cond ((eval (read cmdString)))
5.          (t (load fn (strcat "\nUnable to load file " fn)))
6.    )
7.    (princ)
8. )
9.  
10.  

Code - Auto/Visual Lisp: [Select]

1. (include "Test_42" "TestCode.lsp")
2. ;;
3. ;;
4. (test_42)
5.  

Test Routine:

Code - Auto/Visual Lisp: [Select]

1.  
2. ;; File TestCode.lsp
3.  
4. (defun test_42 ()
5.    (prompt "\nFourty")
6.    (prompt " two")
7.    (princ)
8. )
9.  
10.  

[irneb]

In short. The effect of an include statement in C can be duplicated using a load call in Lisp. ...

Don't do that (it creates a spaghetti mess).

That is EXACTLY why the C's include directive is a mess. It creates such spaghetti code all over the place. I.e. to answer the OP ... to get the EXACT same thing as C's include directive, just load the other file - the same thing happens: load instead of copy+compile.

If you want something like a Common Lisp's requires function ... that's not what include does in C, so it's not what the OP asked for. Even though it's a much better alternative.

[JohnK]

The INCLUDE statement does not increase compile time; it speeds it up. INCLUDE does not make spaghetti code; it keeps code more organized.

...Having the same/slightly modified/updated support function copied in several files makes for a huge mess; one steps on the others toes or undoes something needed by this version. Support functions get copied and pasted and get updated but no one goes back through all their files and updates all of the function's instances.

[Jeff H]

Does AutoLisp have a "last one loaded wins" approach?

[JohnK]

Does AutoLisp have a "last one loaded wins" approach?

Yes. ...Some times it can be a problem when a support procedure--that uses the same name but has been altered--localizes or changes global vars different then the one the procedure is expecting or had. This comes into play a lot when old/unmaintained code is used and/or loaded in the incorrect order.

[irneb]

The INCLUDE statement does not increase compile time; it speeds it up. INCLUDE does not make spaghetti code; it keeps code more organized.

...Having the same/slightly modified/updated support function copied in several files makes for a huge mess; one steps on the others toes or undoes something needed by this version. Support functions get copied and pasted and get updated but no one goes back through all their files and updates all of the function's instances.

Four points in response:

(1) I'm assuming you are talking about the C programming language, or perhaps even the C++ language. NOT the C# language, which has an entirely other way of going about such includes. If I'm wrong in this, then disregard everything I've posted about it - we're talking about apples and pairs if so.

(2) As I understand the "spaghetti" code: it's that you end up with lots of inter-dependent source files which fail if only one of them is missing. Or even worse, when some function in one is overridden in another to do something else. This is exactly the same thing which occurs in C's include - see below.

(3) A C include statement is nothing else than a "copy that file into this spot before compiling". This means that if you #include FileA into FileB, then it's as if you opened FileA, selected all, Ctrl+C, swapped to FileB and Ctrl+V. If you don't believe me, see the answers from experts:
http://stackoverflow.com/questions/5735379/what-does-include-actually-do
http://www.cplusplus.com/forum/articles/10627/
http://stackoverflow.com/questions/1539347/what-are-ways-of-improving-build-compile-time
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka4022.html

(4) So when you have FileA "included" into more than just one single other file, the compile-time will get increased because it will literally compile the same code more than once (note literal meaning of the word literally). This gets worse when you're including a file which includes other files on its own. You can very easily have a source file only a few lines long, including one or two others, which then expands through the pre-processor into 1000's of lines of source code for the compiler to handle. And it's worse in C than in Lisp's last-loaded-wins approach, because the compiler may compile any file in any order, especially as it may be set to compile using multiple threads - so you cannot even say for sure which "version" of a function will be the final one which is in the compiled result.

There's actually a way to try and avoid this issue in C. It's called "include guards": http://www.cplusplus.com/forum/general/71787/

A similar approach in Lisp would be to check if a function is already defined before loading it, e.g.:

Code - Auto/Visual Lisp: [Select]

1. (if (not MyFunc)) (load "MyFile"))

This does the same as a C construct like this: The file to be included needs to define a pre-processor definition to enable other files to check

Code - C: [Select]

1. #ifndef _MY_FILE_ //Only define if it's not already defined
2. #define _MY_FILE_ //Define the pre-processor directive
3. #endif // End of if block
4.  
5. // The rest of the code inside the MyFile.C/H source

Then in the other files you do the following:

Code - C: [Select]

1. #ifndef _MY_FILE_ // Check if the file's not already included somewhere else
2. #include "MyFile.C/H" // Copy the file into this spot
3. #endif
4.  
5. // Rest of code for this other file

To me the Lisp way is a lot less convoluted, it's a simple one-liner (strictly speaking 2 lines, if and load), you don't need to edit the file to be loaded, and all you need to know about it is one of its defun names (which you should already since you want to use them). Even if you try to do the exact same in C it gets very hairy: http://stackoverflow.com/questions/6916772/can-i-re-define-a-function-or-check-if-it-exists

[JohnK]

One acronym response (read as humor; I'm not trying to be an a55).
LiFP
I built all of that, and more into LiFP. I'm sure you can set up all of those/the methodologies with plain alisp. Reini already did; use his like Kerry suggested (Why redo something that is already done/can work for you) but I really tried to bring a a more robust development methodology to autolisp then "load".

Honest question: how many times have you written "getpoint", "begin undo", "error", etc.? ...When I was writing in lisp I must have wrote those generic functions a thousand times. I imagine that I copied them quite a bit but I would venture a guess that I just re-wrote more often than not. That was a mess; I had several versions of the same function in several different programs (with slightly different names too--"get_point", "get-point", "myGet-Point"-). Later I got more organized and created utility files but that just eventually created a maintenance mess (my paths had to be kept up as well as the files and functions in them). This also created bloat (like what I think you're referring to with c#). ...not to mention, trying to compile with that method was worthless.

When I set up LiFP I hid the include statement and preprocessor directives behind a comment character so the programmer can chose either method (preprocess or load) if they choose or wanted to set it up. I also built in a simple include guard so there wasn't any of that headache associated. I also made LiFP work with makefile so tasks could be automated [-i.e. like creating packages or updating network deployments or fetching code from or to the internet. ...automation].

I put a lot of work into designing LiFP and into it's support [-e.g. I built a sample stdlib someone could use as a starting point for their own. I made sure I included examples of how to use it with makefile. I even showed how you can use it to build a webpage.].

Now, all that said, do I think the OP, you, or anyone besides the few users that already do will actually try LiFP? No; Autolispers just want to open, write, and load. They do not want to think about any of the problems associated with having a lot of files/code to maintain or how to deploy their code to the network or even work in a group. They don't care or want to think about organization (put code in a file, put that file in a folder[maybe], load and go).

I know/`believe you'/understand how C's include statement works.
I know what an include guard is. ...BTW, step into the 1990's and use "#pragma once".

[It's Alive!]

I used #pragma once

[JohnK]

lol

[irneb]

I'm no saying that standard AutoLisp's load is very good. It has lots of problems. I'm just saying that it's nothing worse than C's include.

I'm sure that something like LiFP is a much better alternative to any of ALisp, C or C++ 's standard multi file handling methods. Though as I see it (note I've not used LiFP much) it's a lot closer to a full macro preprocessor, much like the one usually found in C or C++. If I'm not mistaken then it's not going to help a lot in keeping someone from writing spaghetti code. The spaghetti code is more a symptom of the language itself ... I.e. it allows the same function to be redefined without adequate (or even any warning). Whereas something like the enforced name spaces in C# or Java would disallow any such repurposing of a function's name just willy nilly.