#: 32323 S2/Clipper Programming
23-Sep-89 18:22:54
Sb: #5.0 Overview
Fm: Paul 'Skip' Moon 73377,710
To: ALL

Everyone:

I'm taking a few minutes out from wrapping up the release of my SUBNTX()
function (I'll get right back on it Richard) to describe some of the features
of 5.0 presented at our last user group meeting.

Since Dianne Lask has agreed and even encouraged discussing it, I will give a
one line overview in this message and then begin a separate, more detailed,
thread on some of the subtopics. They will all begin "5.0 - " and then give
the subtopic.

I'll try to be as accurate as possible, but there are a few things I'm not
clear about. This is almost like gossip, third hand, so please do hold me
responsible for mistakes.

--------------------
CLIPPER 5.0 OVERVIEW
--------------------

1. Built in Preprocessor
2. New variable types
3. Code Blocks
4. User defined commands
5. Code Optimizer
6. New compiler switches and environment variables
7. New Operators
8. Rtlink

1 Reply

#: 32324 S2/Clipper Programming
23-Sep-89 18:23:21
Sb: 5.0 - User Defined Cmds
Fm: Paul 'Skip' Moon 73377,710
To: ALL

---------------------
User Defined Commands
---------------------

UDCs (User Defined Commands) are similar to, but different from, C
preprocessor macros. (Clipper 5.0 will also have preprocessor macros, not
to be confused with ¯os.) An example UDC might be:

#command SET WORKAREA TO => SetArea()

FUNCTION SetArea(areaNum) && Notice something new here? See thread on
SELECT (areaNum) && 5.0 - Variables.
RETURN(.T.)

The stuff follows the same syntax rules as the command descriptions in
the manual. ie. [] means optional parameters.

The result of this UDC allows you to say: SET WORKAREA TO 5. The
preprocessor will actually convert this to: Setarea(5).

One other neat thing is that 5.0 will come with the file STANDARD.CH. It
will include #command type descriptions for ALL Clipper standard commands.
For instance it wil probably have one line that defines (my favorite
command ) SKIP:

#command SKIP [ALIAS ] [] => skip(,)

This is just my guess on this specific syntax. For one thing, I don't know
if it will handle "keywords" like ALIAS.




#: 32325 S2/Clipper Programming
23-Sep-89 18:23:44
Sb: #5.0 - New variable types
Fm: Paul 'Skip' Moon 73377,710
To: ALL

------------------
New Variable Types
------------------

New 5.0 variable types include:

LOCAL type
STATIC type
FIELD declaration (not really a type)
MEMVAR declaration (not really a type)

Two new descriptions Nantucket uses to describe properties of variables are:

Lifetime - When and how long the variable exists and retains its value.

Visibility - Whether it can be actually accessed or not.

LOCAL
-----
The new LOCAL var type, a "stack" variable, is never recorded in the symbol
table (and so can't me ¯o'd). Its lifetime and visibilty begins at the
start of the function. It is visible only while IN that function, not while
in a function it may call. Its lifetime and visibility ends when that
function returns.


[More]


3 Replies

#: 32326 S2/Clipper Programming
23-Sep-89 18:24:14
Sb: #32325-#5.0 - New variable types
Fm: Paul 'Skip' Moon 73377,710
To: Paul 'Skip' Moon 73377,710 (X)

[Continued]

LOCAL variable continued
-----
An example of LOCAL variable in function.

FUNCTION somefunct
LOCAL lvar
lvar = "I'm Local"
? "This is a local variable..."
?? lvar
funct2() && lvar isn't visible in this function
RETURN(.T.) && lvar will no longer exist


The method of declaring the PARAMETERS of a function to be LOCAL instead of
PRIVATE are in the () after the function definition. ie.

FUNCTION somefunct( lparam )
? "This is a local variable..."
?? lparam
RETURN (.T.)


[More]


1 Reply

#: 32327 S2/Clipper Programming
23-Sep-89 18:24:34
Sb: #32326-#5.0 - New variable types
Fm: Paul 'Skip' Moon 73377,710
To: Paul 'Skip' Moon 73377,710 (X)

[Continued]

STATIC
------

A Static variable's lifetime begins when a value is first stored to it, and
persists for the rest of the program life. It can, however, only be
accessed while in that function.

FUNCTION incr_count
STATIC counter
if counter = NIL && new type, in other words if type("myvar")=="U"
counter:= 0 && new optional assignment operater :=
else
counter:= counter + 1
endif
RETURN (counter)


FIELD declaration
-----------------

The FIELD declaration is used to denote particular variables which will
default to represent Fields in the current area. It can be overridden with
the optional M-> operator.


[More]


1 Reply

#: 32328 S2/Clipper Programming
23-Sep-89 18:25:00
Sb: #32327-#5.0 - New variable types
Fm: Paul 'Skip' Moon 73377,710
To: Paul 'Skip' Moon 73377,710 (X)

[Continued]

MEMVAR declaration
------------------

The MEMVAR declaration, conversely to the FIELD declaration, denotes a
variable to default to representing the actual memory variable (as opposed
to the field) in the current area. It can be overridden with ->
operator.

NIL type
--------

At this point I really should rephrase the word I've been using for type.
It is really (for lack of a better word) a variable kind or attribute.
There should be a distinction between a Type such as: Character, Numeric,
Date, Logical, (new) Nil, and a variable Kind(?) such as PUBLIC, PRIVATE,
LOCAL, and STATIC.

Anyway the type NIL is used to denote the value of a variable before it is
assigned any value. I'm a little confused here. I don't know if it is also
the value of a variable that has not yet even been defined. For instance
can you say:

PUBLIC var1, var2
var1 = 0
? (var1=NIL) && False
? (var2=NIL) && True
? (var3=NIL) && I don't know if this is valid, even though
&& ? (type("var3")="U") would be.


[More]


1 Reply

#: 32329 S2/Clipper Programming
23-Sep-89 18:25:15
Sb: #32328-5.0 - New variable types
Fm: Paul 'Skip' Moon 73377,710
To: Paul 'Skip' Moon 73377,710 (X)

[Continued]



This is taking longer than I thought, and I have barely scatched the surface.
I'll post some more details including ARRAYS AND CODEBLOCKS later.

{Skip}


#: 32481 S2/Clipper Programming
25-Sep-89 08:41:55
Sb: #32325-#5.0 - New variable types
Fm: Mary E. Matthews 76010,3546
To: Paul 'Skip' Moon 73377,710 (X)

Skip,

Okay - then we can use both LOCAL and regular parameters of a function by:

FUNCTION somefunc( lparam ) -or- FUNCTION somefunc
PARAMETERS par1, par2 PARAMETERS par1, par2
... LOCAL lparam
func2() ...
return (.t.) func2()
return (.t.)

Is that correct, do you think? And par1/par2 are private but since they are
_not_ LOCAL will be visible to func2() whereas lparam will not ?


-Mary






2 Replies

#: 32555 S2/Clipper Programming
25-Sep-89 18:27:31
Sb: #32481-5.0 - New variable types
Fm: Paul 'Skip' Moon 73377,710
To: Mary E. Matthews 76010,3546 (X)

Mary:

I think I need to say in all my messages "As I understand it..."

Now about the parameter question. Nothing was mentioned at the lecture about
using BOTH PRIVATE and LOCAL PARAMETERS at the same time. Therefore I can only
guess that you couldn't. For one thing, if you could, which actual parameters
would correspond to the formal parameters in the function definition? Just a
guess.

Also you're right that PRIVATE would be visible to func2() but LOCAL would
not. (I assume that holds true for PRIVATE parameters as well as just PRIVATE
variables.)

{Skip}




#: 32577 S2/Clipper Programming
25-Sep-89 21:44:24
Sb: #32481-5.0 - New variable types
Fm: Savannah Brentnall-Sysop 76702,277
To: Mary E. Matthews 76010,3546 (X)

Mary,

Good question. I think you can accept the parameters as LOCAL, then
declare some of them PRIVATE, but I'll check it out.

Savannah




#: 32482 S2/Clipper Programming
25-Sep-89 08:42:15
Sb: #32325-#5.0 - New variable types
Fm: Mary E. Matthews 76010,3546
To: Paul 'Skip' Moon 73377,710 (X)

Skip - or anyone,

re STATIC variables - You say it can be accessed only from its own function -
does that mean it is not visible to lower level functions or that it can only
be changed within its own function?

It occurs to me that NIL may allow us to distinguish between the contents of;
e.g., a numeric field that has had a zero value entered into it and one that
merely evaluates to zero since nothing has actually been entered. I do hope
that is true.

-Mary

p.s. I really don't expect you to know all the answers, Skip.





2 Replies

#: 32576 S2/Clipper Programming
25-Sep-89 21:44:13
Sb: #32482-5.0 - New variable types
Fm: Savannah Brentnall-Sysop 76702,277
To: Mary E. Matthews 76010,3546 (X)

Mary,

It is my understanding that NIL will always return .F. on fields,
because they always have a value, even if it's zero. I see your point, though.

Savannah






#: 32330 S2/Clipper Programming
23-Sep-89 18:25:38
Sb: #5.0 - New Operators
Fm: Paul 'Skip' Moon 73377,710
To: ALL

-------------
5.0 Operators
-------------

:= New optional assignment operator.

It returns a value so can be used in expressions:

if ( (handle:=nextchar()) != EOF )
do this
endif

Also multiple assignments: x:=y:=z:= 0

Also can assign into fields instead of using REPLACE.

test->f1 := "this goes into field one"


== operator
-----------
Exact comparrison and also for arrays to test for equivelence (stored in the
same memory area) instead of just equality. (More details in arrays thread.)

++ increment operator (post and pre)
---------------------

-- decrement operator (post and pre)
---------------------

More later, {Skip}

4 Replies

#: 32460 S2/Clipper Programming
25-Sep-89 03:53:03
Sb: #32330-#5.0 - New Operators
Fm: Diane Lask [Nantucket] 72460,1247
To: Paul 'Skip' Moon 73377,710 (X)

Paul, I'm afraid that you put me in a somewhat uncomfortable position. By and
large you have done a rather nice job in relaying what you had heard in the
user groups. You do bring up some points that you pretty much request
clarification of or that you state are a bit unclear on. My impulse is to
provide such clarification to you immediately. However, I really hope that
you (and the others on the forum) will bear with me for a while. I really
must restate my desire not pull the carpet out from my co-workers who are
currently giving the 5.0 details to the user groups. I can envision the user
group members, after hearing all the nifty things from the Nantucket speaker,
coming up with an 'oh yea, we already heard that on CIS - tell us something
else' sort of feeling. I really do not want to be the cause of that. By all
means continue to discuss what you will - but BE CAREFUL of the information
that you relay - it does change from time to time. If you all will bear with
me for a few weeks I'll promise to provide you all with LOTS of interesting
stuff WEEKS before you get the product. Hope that you understand.

Diane


#: 32418 S2/Clipper Programming
24-Sep-89 19:32:11
Sb: #5.0 - New DATA Types
Fm: Paul 'Skip' Moon 73377,710
To: ALL

DATA Types
----------

I just remembered the names I was looking for in a previous message to
distinguish these two groups:

DATA TYPES vs VARIABLE TYPES
---------- --------------
Character Public
Numeric Private
Date Local
Logical Static
Arrays (semi new)
Nil (new)
Codeblock (new)

I've already discussed the NIL type. Now I'll start a thread on Codeblocks
and Arrays.

Remember, I'm writing about 5.0 for several reasons:
1. I'd like to share what our group heard with others.
2. When you teach (tell about) something you learn it better yourself.
3. I'd like to get the opinions of others since I'm still not clear on a
few details and practical uses (which I'll point out later).

Because of the third point, please feel free to return your comments and
ideas.

{Skip}

1 Reply

#: 32453 S2/Clipper Programming
25-Sep-89 01:08:56
Sb: #32436-#5.0 - New DATA Types
Fm: Paul 'Skip' Moon 73377,710
To: Gary Baren 75470,1027 (X)

Gary:

Thanks for responding. SCOPE may very well be a better word to use.

However, the definition of SCOPE in one of my 'C' texts says "The scope of a
variable refers to part(s) of a program for which a variable is visible or
available for use." This sounds like what Nantucket was calling "Visibility."

In this example a variable LOCAL to func1 is not 'VISIBLE' to func2. This is
scope or visibility.

FUNCTION func1 FUNCTION func2
LOCAL lvar .
func2() * We can't see lvar here, even though it
RETURN .T. * still exists.
.
RETURN .T.

Another word they coined was "Lifetime." In the example above, the lifetime
of lvar begins when func1 is called and ends when func1 returns.

I was looking for a 'Set Name' or 'Catagory Name' that had the members:
PUBLIC, PRIVATE, LOCAL, STATIC. Since SCOPE (visiblity) is only one attribute
describing these members, I didn't use it. But, maybe we'll all decide its a
good word to use. I think Nantucket used "Variable Type."

{Skip}

3 Replies

#: 32419 S2/Clipper Programming
24-Sep-89 19:32:26
Sb: #5.0 - Arrays
Fm: Paul 'Skip' Moon 73377,710
To: ALL

Arrays
------

Arrays are listed as a new type in 5.0 because they are so different. Some
new properties are:

- The array name is a place holder (semi pointer) to an area of memory.

- An array can be ASSIGNED to variables. ie:
a:= [ [1,2,3] ] && created by list
b:= a && assigned to another variable

- Arrays can be RETURNED from functions.

- Arrays can be created by specifying a LIST of values. (As shown above.)

Using the 'exact' comparrison operator, '==', you can test for equivilance
(as opposed to equaility). Equivilance means it occupies the same area of
memory, not just the same value. ie.

a:=[ [1,2,3] ]
b:=a
c:=[ [1,2,3] ]
? (a==b) && .t. Equivalant
? (a==c) && .f. Equal


[More]




2 Replies

#: 32420 S2/Clipper Programming
24-Sep-89 19:32:53
Sb: #32419-#5.0 - Arrays
Fm: Paul 'Skip' Moon 73377,710
To: Paul 'Skip' Moon 73377,710 (X)

[Continued]

ARRAYS contd
------------
This is where my understanding of arrays slows down for now. In college you
SOMETIMES could either take notes, or listen and understand. Being pressed
for time, at this point I succeeded at neither. Here are a few things I
caught, along with some questions.

We have all heard by now that 5.0 arrays can me multidimensional. In 5.0
you can declare arrays in two ways.

PRIVATE a[1,2,3] or PRIVATE a[1][2][3]

I believe this declares a 3 dim array. However I also have in my notes:

a[1,1,1] := "Hello" && This looks like it initializes a single
&& element of the 3 dim array, but I thought
&& she said you init all elements at same time?

a:=[ [1,2,3] ] && This is an optional way to initialize an
&& array, but are we now talking about 3 element
&& values of a sinle dim array?
I dont't have any other examples in my notes. If there is someone else who
has attended the talk, please set us straight. Arrays look like they will
become even more usefull, but in the few examples I've seen the syntax is
confusing.

I wish they could have used initialization similar to 'C' where element
lists where enclosed in {}. But that is a symbol used in Codeblocks which
I'll introduce next.


2 Replies

#: 32451 S2/Clipper Programming
24-Sep-89 23:00:05
Sb: #32420-5.0 - Arrays
Fm: Kathy Hayes 71620,211
To: Paul 'Skip' Moon 73377,710 (X)

Skip,

You did a great job of taking notes (and understanding too! ).

I sat there trying to just listen and understand, but somewhere around the
beginning of the second hour, my brain reached overload, I got a silly grin on
my face, and I kept saying to myself, "Geez, I can't wait to get my hands on
this."

Savannah did a terrific job of presenting all the material, but by the time
she was done, I think everyone was too numb to ask questions. Plus we were
all anxious to find out who won the free copy...which turned out to be none
other than Ben Snow.

Kathy


#: 32421 S2/Clipper Programming
24-Sep-89 19:33:14
Sb: #5.0 - Codeblocks
Fm: Paul 'Skip' Moon 73377,710
To: ALL

CodeBlocks
----------

Savannah warned that it might take a while to understand the full
significance of codeblocks. I believe I understand the technicalities of
how they work but I'm not clear on the benefits of using them. To me they
are similar to 'C' pointers to functions, but with a syntax resembling
object oriented languages.

Codeblocks are blocks of code which are defined like these:

charCode := { (data) data }
numCode := { (data) LTRIM(STR(data)) }
logCode := { (data) IF(data, "TRUE", "FALSE") }
dateCode := { (data) DTOC(data) }

Notice the part in {} is ASSIGNED to the variable on the left which is then
of type CODEBLOCK. The part in the {} is similar to a function, with the
Codeblock variable being similar to a function pointer. Formal parameters
are declared in the () at the start of the codeblock. ie. (data). Then
those parameters are used in the rest of the codeblock.

At first I assumed these were simple examples and that multiple statements
might be allowed in each codeblock. However, looking at the examples that
follow, I noticed that the RETURN value is the value of that ONE line.

(Also, I might say here that I had heard multiple commands could occur on
single lines in 5.0, but no examples were mentioned.)

[More]


2 Replies

#: 32422 S2/Clipper Programming
24-Sep-89 19:33:34
Sb: #32421-#5.0 - Codeblocks
Fm: Paul 'Skip' Moon 73377,710
To: Paul 'Skip' Moon 73377,710 (X)

[Continued]

CodeBlocks continued
----------
Now, how to use codeblocks. Referring to the codeblocks listed above,
here's an example of calling a function which uses one:

SAYDATA("Hello",charCode) && Called using charCode, a variable of
&& type codeblock

FUNCTION SAYDATA( dataPassed, aCodeBlock)
* Also notice using LOCAL parmeters in the function definition.
@ 10,10 SAY aCodeBlock:eval(dataPassed)
RETURN .T.

The first new thing to notice is the function eval() following the colon.
Eval() is Clipper's own predefined function which means evaluate the
codeBlock using the parameter[s] if given.

Again, I think of a codeblock variable as a function pointer. So when the
pointer stored in charCode is passed to the function with the formal
parameter 'aCodeBlock', aCodeBlock holds the address of the block of code to
execute. It is executed by using the ':' to indicate performing eval() on
it.


[More]



1 Reply

#: 32423 S2/Clipper Programming
24-Sep-89 19:33:49
Sb: #32422-#5.0 - Codeblocks
Fm: Paul 'Skip' Moon 73377,710
To: Paul 'Skip' Moon 73377,710 (X)

[Continued]

CodeBlocks cont'd
----------
I began to think about how passing a funtion like eval() to a codeblock
seemed to be the beginning of functional OOP in Clipper. You would pass the
message 'eval' to the object charCode. However, Savannah said that eval() is
the ONLY function (or message), you can pass at this time. To me it seems
more like a frustrating tease.

Here's another one of their examples.

LOCAL myVar
myVar := 50
myBlock := {myVar + 10}
NEXTFUNC(myBlock)

FUNCTION NEXTFUNC( blockPassed )
LOCAL myVar
myVar := 200
newVar := blockPassed:eval()
* BlockPassed uses the myVar==50 instead of the myVar==200 in this
* function. Therefore, newVar will now be assigned the value 60,
* NOT 210.
RETURN .T.

[More]


1 Reply

#: 32424 S2/Clipper Programming
24-Sep-89 19:34:12
Sb: #32423-#5.0 - Codeblocks
Fm: Paul 'Skip' Moon 73377,710
To: Paul 'Skip' Moon 73377,710 (X)

[Continued]

CodeBlocks cont'd
----------
Now I'd like to discuss and question the philosophy of applying codeblocks
to our programming.

Someone mentioned using it for color variables, but no real advantage has
popped into my mind yet. I'm open though. I'm not being negative. Give me
your opinion.

Someone suggested using it in a communications application. No specifics
were mentioned.

Here are a few thoughts I've had lately. Trying to implement OOP, could
you think of the codeblock variable as a message itself, instead of saying
you're passing IT the message eval()? Naaaaaaahhhh. I just tried it in
every way I could think of, but it didn't look good.

[More]


1 Reply

#: 32425 S2/Clipper Programming
24-Sep-89 19:34:29
Sb: #32424-#5.0 - Codeblocks
Fm: Paul 'Skip' Moon 73377,710
To: Paul 'Skip' Moon 73377,710 (X)

[Continued]

CodeBlocks cont'd
----------

Here's about the only way I can think of to use the codeblock variables as
messages themselves.

USUAL WAY CODEBLOCK WAY
--------- -------------
menu_one("display") display := {displayit()}
menu_one( display )

FUNCTION menu_one FUNCTION menu_one( action )
PARAMETERS action action:eval()
DO CASE RETURN .T.
CASE action == "display"
displayit()
.
. (Zillions of case
. statements here)
.
ENDCASE
RETURN .T.


[More]



1 Reply

#: 32426 S2/Clipper Programming
24-Sep-89 19:34:54
Sb: #32425-#5.0 - Codeblocks
Fm: Paul 'Skip' Moon 73377,710
To: Paul 'Skip' Moon 73377,710 (X)

[Continued]

CodeBlocks cont'd
----------

PERHAPS THE BEST WAY
--------------------

#define DISPLAY 1

menu_one( DISPLAY )


FUNTION menu_one( action )
DO CASE
CASE action == DISPLAY
displayit()
.
. (Zillion case statements anyway)
.
ENDCASE
RETURN .T.

I think I'll stop here and allow others to express their opinions or
questions. Sorry for taking up so much message space, but I hope its useful
food for thought.

{Skip}

Now back to subntx()


2 Replies

#: 32554 S2/Clipper Programming
25-Sep-89 18:27:09
Sb: #32477-#5.0 - Codeblocks
Fm: Paul 'Skip' Moon 73377,710
To: Steve Larsen 76370,1532 (X)

Steve:

I have not heard personally whether the extend system will be supported or
not. If they said one way or another, I don't know.

Savannah did say that current libraries such as ProClip and others will work,
but I don't know if that's because those select 3rd parties may have been
given information to change it or not.

My own impression at Devcon was that those libraries that went BEYOND extend
by accessing internals (like Getit) would have the help of Nantucket in
preparing for 5.0. I just assumed that the main extend system would remain
pretty much the same since we've all be told to "be safe" and use the extend
system. (ie. _xmgrab instead of malloc ) I use malloc anyway.

{Skip}



#: 33131 S2/Clipper Programming
29-Sep-89 18:35:53
Sb: #32868-5.0 - Arrays
Fm: Savannah Brentnall-Sysop 76702,277
To: Brice de Ganahl 76244,1152 (X)

Brice,

LOCAL variables are stored on the stack, unlike PRIVATEs and PUBLICs.
See my message to Charles for more info.

Savannah




#: 33130 S2/Clipper Programming
29-Sep-89 18:35:45
Sb: #32771-#5.0 - Arrays
Fm: Savannah Brentnall-Sysop 76702,277
To: CHARLES YEO 72357,1666 (X)

Charles,

LOCAL variables are stored on the stack, which means they're much
faster than PRIVATEs or PUBLICs. They don't have symbol or memory variable
table entries, etc.

Savannah




#: 33622 S1/General Information
04-Oct-89 10:10:09
Sb: Clipper 5.0
Fm: Kathy Hayes 71620,211
To: All

Since there's been some recent discussion of EXE size, I've been trying to
remember something Savannah said during her presentation.

If I heard and understood correctly, she said that the new optimization
techniques would be much more discerning and would only pull in those things
it truly needed. For example, if you were to write a program that didn't use
any files, none of the file handling stuff would be included. It seems to me
that this would mean the "hello world" program would be considerably smaller
than it is with S87.

I have to admit that I was overwhelmed by all she told us. Does anyone else
have any thoughts on this?

Kathy


#: 33839 S2/Clipper Programming
06-Oct-89 14:02:15
Sb: #33790-Clip5 Memory Management
Fm: Francis G Dorsemaine 72301,3134
To: Co-Nghiep Ho 72431,636

Welcome on board!
My understanding is that .RTLink memory manakement is based on pages of
memory (2k-4k cant remember) and will call in/out these pages as requested.
This should therefore allow you to have freed memory for your large strings.
The memory management will also handle a least read method. Perhaps someone
with better understanding/memory will step in. Regards. Francis.