Contexts. Contexts. Contexts. Contexts.

[m i c h a e l]

After my first few blundering attempts to impose upon newLISP my "baggage" programming tricks, I realized (with Lutz's patient help) the way into newLISP was not by force, but by acceptance. (This is beginning to sound like a self-help group meeting testimonial. How's that for a study: Programming Language Communities and Their Therapeutic Effects ;-)

One thing I'm seeing is that the myriad ways of testing, recording information about, and even classifying functions can be elegantly handled by contexts.

All of my functions for testing are in the testing context. Documentation can be found in the docs context. I put my global functions into the user context. After that, I make the function name a global constant holding the user-function from user. A skeleton of a file following this pattern looks like this:

Code: Select all

(context 'user)

	(define (f a b)
		(+ a b (- b a)))
		
(context MAIN)

(constant (global 'f) user:f)

(define (docs:f)  ; not making any new symbols
	(show {f
		syntax: (f int-a int-b)

		What the function does.

		example:

			> (f 1 3)
			6
			> (f 3 1)
			2
			> _}))
			
(context 'testing)  ; making new symbols

	(define (testing:f)   ; context is needed (not the global f)
		(let (f. MAIN:f)  ; and so is MAIN (not testing's f)
		(test=
			(f. 1 3) 6
			(f. 3 1) 2
			(f. 1 1) 2
			(f. 3 3) 6)))
			
(context MAIN)

The functions show and test= are user-defined, and since they aren't vital to the discussion, I will just alert you to their existence. Also, the decision about whether or not to switch contexts before defining the test or doc functions depends on if I'm introducing new symbols. Usually, the testing functions end up needing new symbols, but docs rarely does.

Now, at the command line:

Code: Select all

> (docs:f)
|
f
syntax: (f int-a int-b)

What the function does.

example:

        > (f 1 3)
        6
        > (f 3 1)
        2
        > _
|
> (testing:f)
testing:passed
> ;; I also modified Lutz's *help* macro to use the function 
> ;; in *docs* (if there is one) for all user-defined functions
> (help f)
|
f
syntax: (f int-a int-b)

What the function does.

example:

        > (f 1 3)
        6
        > (f 3 1)
        2
        > _
|
> _

All of the tests for my functions are now located in just one context. The same goes for the documentation and user-defined functions used globally.

I think contexts are just begging to be explored for ways of structuring and reasoning about our newLISP programs.

This leads me back to somewhere close to where I started. And that is the acceptance of the language as it is. Nothing about a programming language is happenstance. Everything is there for a reason (although that reason may no longer be valid, hence the need for continual development). If I look at a language and see only ways it can be made more like this or that language, can I really say I'm seeing the language for what it is? If you look at your significant other and see only ways that person could be different, are you really accepting them as they are? Once you accept the language (and by this, I really mean its nature), you begin to see new ways of doing things and to feel the excitement of exploration again. With that, we can discover the beauty that is newLISP. If we were so impressed with our old language, why are we looking for another one?

As part of this exploration, I wondered if we could use contexts to classify even the built-in functions (lists, arrays, strings, maths, matrixes, i/o, etc). This way, we could see all the functions of certain types:

Code: Select all

> (symbols strings)
(strings:address strings:append strings:char strings:dup 
 strings:ends-with strings:encrypt strings:eval-string ...)
> _

We could add our user-defined functions to these classifying contexts, in addition to whatever context(s) they happen to be in.

I've really just started to think about the ways contexts can be used, but already, I'm seeing there is more there than meets the eye.

m i c h a e l

[cormullion]

good post, m i c h a e l. I will try and work through this soon.

I think that one of the problems with learning new things is that the brain can only learn by extending what it already knows, yet this means that you interpret new things with reference to existing things: by saying that 'symbols are like variables', you then start forgetting that they can also be like something else. At least that's what I'm finding!