SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Sun, 13 Feb 2005 22:42:39 PST8
From:	Peter Skye <pskye@peterskye.com >
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: Open Source Object Rexx

Content Type: text/plain

Lynn H. Maxson wrote:
>
> "My point (I can't speak for Greg) is that sometimes you want
> exactly the value that you put in, not an approximation no
> matter how low the error of the approximation."
>
> You have to be kidding me. You can't do it by hand. You
> can't do it by hardware. You can't do it by software. I take it
> back. If you are willing to do a calculation on an infinite
> length number like 2/3, you can start the calculation. It will
> never finish. You can write an non-ending algorithm. You will
> still never know the result.

You gotta be kidding. They teach fractional arithmetic in junior high.
And those kids still do it by hand. And they get the right answer (if
they pass the course).

> "Righty-o. Try the value 1/3. I can store it as a
> numerator-denominator pair in two bytes, or I can store it as
> a close approximation using "all available memory"."
>
> Well, Peter, you can and you can't. Assume you can define
> such a fractional data type. When you do you have to specify
> the width of the numerator and denominator. Let's say that
> we define it as "dcl mynum ratio (1,1) init(1/3);". Now where
> do you define the precision you want?

That is *NOT* what we are talking about and you know it. You are
ignoring the question so that you can pontificate about something else.
We are talking about data types, something which your programming
language doesn't explore.

Your counter-argument is typically "well heck, just put it in the
specifications and then regenerate the compiler". Why not put it in the
compiler, or in an add-on library, to begin with? Why regenerate the
entire compiler to just handle something like, for example, a fraction?
And how are you going to tell all your open-source cohorts which version
of the compiler to regenerate? Putting the data types into the compiler
solves that problem, too.

> "Stop restricting the data types to what your own hardware
> considers "native"."
>
> Not guilty. Never.

Hah! Where's your support for Pascal ordinals?

> "Sounds like you want to offer open source algorithms. I'll
> buy into that; no programming language necessary."
>
> You write an algorithm. I'll show you at least a specification
> language, if not a programming one.

I accept your challenge. Here's some fractional math:

If X=A/B and Y=C/D
then X*Y = (A*C)/(B*D)

You said you'll show me the specification language. Here's some space
-- I'm waiting:

Don't forget to say which specification language you're using.

> "I'll admit to very little experience with specification
> languages, but here's my simple test: Can a spec written with
> Specification Language A be directly convertible to
> Specification Language B? ..."
>
> See. I knew you weren't listening. How many times must I
> repeat that every programming language is a specification
> language.

You talk in circles, circles, circles. Is every specification language
a programming language? Is every specification language an algorithmic
language?

Every reader here will notice you did *not* answer the question: "Can a
spec written with Specification Language A be directly convertible to
Specification Language B?" This is as obfuscated as a course in
philosophy.

> direct convertible always occurs from a non-universal
> to a universal specification language. It may or
> may not occur in the other direction.

Good, a mite of progress. You say there are universal specification
languages and non-universal specification languages.

Here are four acronyms for specification languages or parts thereof:

LEX
YACC
PL/E
SL/I

What other popular universal specification languages can you think of?
(Lurkers: If you play chess you'll know what's coming -- in my next
message I'm going to ask Lynn if the specs in each of these USL's are
directly, completely and automatically convertible to any of the other
USL's.)

> "Darn it, Lynn, stop saying "No". If this project has merit, then
> let it out the door."
>
> I have an open door. You apparently have a closed mind.

I like open doors. I like your Warpicity idea. I like PL/I and I've
been playing around with PL/I extensions since the late '60s (we called
them "preprocessors" and we didn't restrict them to just the PL/I level
E preprocessor).

Near as I can fathom your matrix, it is

Open Source
Specification Languages
Universal Specification Languages
SL/I
Non-Universal Specification Languages
PL/I

Six years. Six lines. I feel like this project is in perpetual
neutral.

- Peter

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"postmaster@scoug.com".

=====================================================

Return to [ 13 | February | 2005 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.