Very Computer

Notes on Data Typeing

The strongest data typeing is when you bring a financial statement
generated by your print program to your CFO that says:

Money Made this Month       10000.00
Money Spent this Month      20000.00
Money Left over                BU.RP

Wherein the programmer updates his resume and looks for another job.

From a standpoint of compilers, data typeing has another
function.

In a strongly typed language variables must be declared
before being used. This has a primary purpose in that it makes
compilers easier to write.

determine text fragment is a varible
lookup in table of variables
if not found send * warning and stop
substitue code that will push x number of bytes on stack
or pop x number of bytes from stack depending on if it's a lvalue or rvalue
and the declared data type has x number of bytes.

What is a byte is implementation specific.

All this does not imply that what is assigned to a variable
at runtime is correct. The programmer can still attempt to force
square pegs into round holes. Once again update resume...

So what does this all mean? Do we need to change our basic compilers?

I think not.

In an earlier thread i proposed a type declaration for a
"recordset" this was a little bit much. It's really a "itemset"

declare inventoryrec as array
    desc as 1
    uom as 2
    cost as 3
    price as 4
    onhand as 5
end declare

dim invinstance as inventoryrec

matread invinstance from inv,iid ...

invinstance(uom) = "each"

Does this gain anything. Not really. the same could be done
without change to the compiler as

equate desc to 1
equate uom to 2
equate cost to 3
equate price to 4
equate onhand to 5

dim invinstance(5)

invinstance(uom) = "each"

It is always up to the programmer to make sure that "each" is
a valid data for uom.

it's always up to the programmer.

----------------------------------------------------------------------

James Roberts Computer Consulting            708/658-9409
----------------------------------------------------------------------

Quote:

>Notes on Data Typeing

[Deleted Stuff]

Quote:>In a strongly typed language variables must be declared
>before being used. This has a primary purpose in that it makes
>compilers easier to write.

This is not really the (compiler) case.  Strong data typing is very important in a multi
programmer environments.  Yes I know we have all gotten along without it, but
is is important.  It is also a management tool.  

Quote:>All this does not imply that what is assigned to a variable
>at runtime is correct. The programmer can still attempt to force
>square pegs into round holes. Once again update resume...

Also true, but with strong data typing the compiler and runtime can catch
these type of things.  For example: SALARY='LARGE'; FICA=SALARY*.15 will
work <g> in pick.  With strong data typing the compiler would catch the
salary data mismatch.  Yes, a programmer could override the checking
(in "c" and other languages) but the "update resume" rule would apply.

Quote:>equate desc to 1
>equate uom to 2
>equate cost to 3
>equate price to 4
>equate onhand to 5

>dim invinstance(5)

>invinstance(uom) = "each"

>It is always up to the programmer to make sure that "each" is
>a valid data for uom.

>it's always up to the programmer.

But why not let the compiler help.  How many times have you and I and many others
had to write a database "fixup" program because someone messed up an equate or used
the wrong subscript.  My BIGGEST complaint with pick has been the lack of DICT
support in basic.  You have this dictionary defining the db fields and basic
simply ignores it and lets you stuff "each" in the numeric field uom.  If the
compiler/runtime would check this we wouldnt have 1000 systems calling support
one day after an upgrade.
--

Phoenix,AZ        Voice: 602.582.9515

Which brings us back to another thread. Are we at that point where we have
programmed ourselves into a corner. With so much code out there is it possible
to rebuild a compiler/runtime that works the way things were supposed to work
and not the way they do.  I think I begin to see why Microsofts Chicago is
taking so long to get to market. It has to still run all the code written for
everything before. Seems to me we could get to a point where the
compiler/runtime gets so big there wont be room for the data.
----------------------------------------------------------------------

James Roberts Computer Consulting            708/658-9409
----------------------------------------------------------------------

But surely problems like this are supposed to be sorted out during testing.

Quote:>From a standpoint of compilers, data typeing has another
>function.

I don't understand what you mean by this.

Quote:>In a strongly typed language variables must be declared
>before being used. This has a primary purpose in that it makes
>compilers easier to write.

Doesn't make the compiler easier to write, infact in some parts will be harder.
I does mean though that variable types are resolved at compile time and
different code is generated based on type (e.g. add of two INTEGERS and
the add of two FLOATING POINT numbers would generate different code instead of
the runtime looking at the stack and determining which subroutine to call).

[..cut..]

Quote:>All this does not imply that what is assigned to a variable
>at runtime is correct. The programmer can still attempt to force
>square pegs into round holes. Once again update resume...

depending on how tight the typing, the programmer may not be able to force it.
It is near on impossible for PASCAL to be fooled into storing the wrong type
of data in a variable.

Quote:>So what does this all mean? Do we need to change our basic compilers?
>I think not.

One of the things that makes BASIC (and C in other appilications) easy and
powerful is the freedom from typing. We need to seriously consider what we give
up when we want to introduce data typing into BASIC.

Quote:>In an earlier thread i proposed a type declaration for a
>"recordset" this was a little bit much. It's really a "itemset"
>declare inventoryrec as array
>    desc as 1
>    uom as 2
>    cost as 3
>    price as 4
>    onhand as 5
>end declare

first comment - why bother with 'as 1, as 2', surely the position in the
definition should be the 'amc'. This is based on the assuption that the
programmer must declare all fields whether used or not.
But why not take this opportunity to define the O/ICONVs to be performed on
each field  ?

Quote:>dim invinstance as inventoryrec
>matread invinstance from inv,iid ...
>invinstance(uom) = "each"
>Does this gain anything. Not really. the same could be done
[..cut..]
>It is always up to the programmer to make sure that "each" is
>a valid data for uom.

if the decalaration had some form of 'data-type-information', then validation
could occur at assignment.
The earlier definition could be written :-

declare inventoryrec as array
    desc as string
    uom as string ('TUOM-MASTER;X;0;0')
    cost as number ('MD2')
    price as number ('MD2,$')
    onhand as number
end declare

And the runtime could assure that cost/price/onhand contain numbers when read
from a file and only numbers are stored in it. The old 'NON NUMERIC' message
would probably become common for a while, but that would pass.

regards,
dave.

------_-_----------------------------------------------------------------------
|     o o      |              David Rose,                    |      .--_|\    |
|      !       |      Fly By Night Programming,              |     /      \   |
|   '''=```    |              Australia.                     |     \_.--.*/   |
-------~-----------------------------------------------------------------v-----
Most people I know think that I am crazy            (.. Billy Thorpe circa 1973)
Especially the "application programmers" on comp.databases.pick  (me circa 1994)

:
:
: >Which brings us back to another thread. Are we at that point where we have
: >
: I agree completely.  There comes a point in time where you have to start looking
: at the problem in a new light. ALGOL went away, "c" and other languages live
: because they dont know to die.  Pick assembly and RPL are mostly gone.  Just
: take a look at what you can do in a few minutes with Visual Basic or for that
: matter MS Access and forms.  I talked to a guy who wrote an entire application
: with nothing more than MS Access (I'm trying a simple project now).  I really
: think that with better tools the days of writting LOOP/REPEATS for most of us
: will soon be gone.  We will become "system designers", connecting OOP object to
: OOP object - DB read object with a caculate invoice total object, etc.  
: --

: Phoenix,AZ        Voice: 602.582.9515
It would be nice to think that this is so but for the same reasons that
CASE and case tools turned out not to remove the need for programmers after
all, the same will be true about OOP. Great idea (but nothing new by the
way) but it will not solve everybodies problem. However, perhaps the
integration of these things can get better in the near future, and
hopefully not through buying 10 disparate pieces of software to try and
make it all hang together somehow.

Jim