Qs about language nomenclature 
Author Message
 Qs about language nomenclature

I have some questions about terms oft bandied about in
describing programming languages.  I didn't find any good sources
of online info at my level, so I'll ask here.

1) concerning variable typing, there are the terms "statically typed,"
"strongly typed", "weakly typed," etc.  probably more that I haven't yet
seen.  I understand that static typing is at compile-time versus
dynamic typing which is run-time.  but what's with "strong" or "weak"
typing?

2) I use fortran and C, which are described as "procedural" and I
believe "imperative." my interpretation of "imperative" is that
the code is saying what to do _and_ how to do it.  is that the key
issue?  likewise, a "functional" language is saying what to do but
_not_ how to do it?  if so, that implies that functional languages
and imperative languages are subsets of procedural languages, correct?

3) there are the terms "sequential," "parallel," and "concurrent,"
not to mention "threading."  sequential I can grasp, and I have
a vague understanding of parallel and threading, but I haven't found
any explanation of concurrent.  I'm guessing the latter three are
related in some sort of set/subset, but haven't found any description.
is there a concise description of these?

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

"There are lies, damned lies, and statistics" -- Benjamin Disraeli
"...and benchmarks" -- Garry Hodgson
---------------------------------------------------------------------------



Sun, 25 Nov 2001 03:00:00 GMT  
 Qs about language nomenclature

Quote:

> 3) there are the terms "sequential," "parallel," and "concurrent,"
> not to mention "threading."  sequential I can grasp, and I have
> a vague understanding of parallel and threading, but I haven't found
> any explanation of concurrent.  I'm guessing the latter three are
> related in some sort of set/subset, but haven't found any description.
> is there a concise description of these?

"Parallel" and "concurrent" are often used interchangeably, but when a
distinction is made, "parallel" means there really are several things
happening at once, while "concurrent" is used to mean languages where
conceptually several things are happening at once but the implementation
may be sequential, involving some sort of timesharing. The point behind
concurrency is that it may sometimes be easier to express a problem in terms
of objects interacting with each other in parallel even if you aren't
intending to map it onto a real parallel arhcitecture.

Matthew Huntbach



Mon, 26 Nov 2001 03:00:00 GMT  
 Qs about language nomenclature

Quote:
> 2) I use Fortran and C, which are described as "procedural" and I
> believe "imperative." my interpretation of "imperative" is that the
> code is saying what to do _and_ how to do it.  is that the key issue?
> likewise, a "functional" language is saying what to do but _not_
> how to do it?  if so, that implies that functional languages and
> imperative languages are subsets of procedural languages, correct?

Not quite. See <http://www.cs.nott.ac.uk/Department/Staff/gmh/faq.html>.

The basic rule is that there are no side effects of functions.
Even no variable assignments! Surprisingly, throwing away such
a fundamental concept gives benefits, e.g. the ability of lazy
evaluation, independence of evaluation order, the ability to pass
and return functions built "on the fly" or using our local values,
referential transparency, some optimizations (e.g. tail recusrion)...
And, most importantly, very clear specification of what a function
means, because a function does nothing more than compute and return
a value, which depends only on its arguments.

--

 \__/       GCS/M d- s+:-- a22 C+++>+++$ UL++>++++$ P+++ L++>++++$ E->++
  ^^                W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP->+ t
QRCZAK                  5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-



Mon, 26 Nov 2001 03:00:00 GMT  
 Qs about language nomenclature

Quote:

> what's with "strong" or "weak" typing?

I don't know if they're formally defined. Roughly "weak" means the type
system can be broken by unchecked casts or whatever, to give undefined
behaviour.

Quote:
> my interpretation of "imperative" is that the code is saying what to
> do _and_ how to do it.  is that the key issue? likewise, a
> "functional" language is saying what to do but _not_ how to do it?

I don't think so. That is a matter of degree; with an imperative language
like C you don't tell the compiler which registers and machine code
instructions to use, so the compiler is working out at least some of the
"how".

The key issue is the approach to time and mutable state. In an imperative
language statements are executed one after the other, in sequence. A
program like:
    a = 1;
    a = 2;

can best be understood as giving different values to 'a' at different
times. That is, 'a' is a variable which has a state, and the state changes
as the code progresses.

In a functional language, mutable state is forbidden. A program consists
of a series of definitions which are not ordered by time. They are more
evaluated on demand. Mutable state is forbidden. A statement like:
    a = 1;

would be seen as giving another name to 1, not as assignment. It could not
coexist with "a = 2" (unless we are somehow talking about different 'a')
because it implies that "1 = 2". 1, 2 and 'a' are all constants.

Further, a functional language is based around the definition and
application of "functions" (in the mathematical sense of the word).

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,

                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."



Mon, 26 Nov 2001 03:00:00 GMT  
 Qs about language nomenclature
Quote:

> what's with "strong" or "weak" typing?

Dave Harris replied (in Part):

Quote:
>I don't know if they're formally defined.

There are several ways these terms are used.
I prefer a definition in Sebesta's text on
Programming Languages.  Roughly a
language is strongly typed if all type
checkingfor a program
can be completed before a
program executes.

The idea is:
Weak<----------------------->Strong
Permissive                             Restrictive
Run Time crashes                     Fewer Run Time Crashes




Wed, 28 Nov 2001 03:00:00 GMT  
 Qs about language nomenclature

Quote:

> I prefer a definition in Sebesta's text on Programming Languages.
> Roughly a language is strongly typed if all type checking for a
> program can be completed before a program executes.

No; that is more commonly called static type checking. As opposed to
dynamic type checking. For example, Smalltalk type checking is both strong
and dynamic.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,

                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."



Thu, 29 Nov 2001 03:00:00 GMT  
 Qs about language nomenclature

Quote:


>> I prefer a definition in Sebesta's text on Programming Languages.
>> Roughly a language is strongly typed if all type checking for a
>> program can be completed before a program executes.

>No; that is more commonly called static type checking. As opposed to
>dynamic type checking. For example, Smalltalk type checking is both strong
>and dynamic.

IIRC, for many years (particulary in the 80's) many people used weak and
strong typing as synonyms for dynamic and static typing, respectively.

--

GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.



Fri, 30 Nov 2001 03:00:00 GMT  
 Qs about language nomenclature

Quote:


> > 2) I use Fortran and C, which are described as "procedural" and I
> > believe "imperative." my interpretation of "imperative" is that the
> > code is saying what to do _and_ how to do it.  is that the key issue?
> > likewise, a "functional" language is saying what to do but _not_
> > how to do it?  if so, that implies that functional languages and
> > imperative languages are subsets of procedural languages, correct?

> The basic rule is that there are no side effects of functions.

Well, the basic rule is that the language is "based" on
functions. This typically means that a program consists only
of value-returning expressions (there are no statements),
that all arguments are passed by value (not by reference),
and that the language emphasises recursion and higher-order
functions rather than loops.

The requirement that there be no side effects is an extreme
position. Functional languages without side effects are
sometimes called pure functional languages.

Quote:
> Even no variable assignments! Surprisingly, throwing away such
> a fundamental concept gives benefits, e.g. the ability of lazy
> evaluation, independence of evaluation order, the ability to pass
> and return functions built "on the fly" or using our local values,
> referential transparency, some optimizations (e.g. tail recusrion)...
> And, most importantly, very clear specification of what a function
> means, because a function does nothing more than compute and return
> a value, which depends only on its arguments.

Lazy evaluation, the ability to pass and return functions built
dynamically, and tail call optimization are not related to the lack
or presence of side-effects. And I'm not sure it's correct to say
that you "gain" optimizations. There are optimizations that you
need in functional languages that don't make sense in conventional
languages, but that isn't necessarily a gain, just a difference.

In any case, any language without side effects is so different from
the underlying hardware that it is always very hard to find an
efficient mapping (compiler) from the language to the hardware.
Such languages are typically much slower than conventional
languages, so it is a bit misleading to say that you "gain"
optimizations. The overall result is that they are slower.



Sat, 01 Dec 2001 03:00:00 GMT  
 Qs about language nomenclature


Quote:
>Lazy evaluation, the ability to pass and return functions built
>dynamically, and tail call optimization are not related to the lack
>or presence of side-effects.

Lazy evaluation only makes sense in the absence of side-effects.

Quote:
>Such languages are typically much slower than conventional
>languages, so it is a bit misleading to say that you "gain"
>optimizations. The overall result is that they are slower.

I refer you to the comp.lang.functional FAQ.

Tim.
--
Tim Goodwin   | `I can't believe that someone is releasing
University of | something called "Unix" without something
Leicester, UK | called "/bin/sh".' -- Randal L. Schwartz



Sat, 01 Dec 2001 03:00:00 GMT  
 Qs about language nomenclature

Quote:
> > Surprisingly, throwing away such a fundamental concept gives
> > benefits, e.g. the ability of lazy evaluation, independence of

[...]

Quote:
> Lazy evaluation, the ability to pass and return functions built
> dynamically, and tail call optimization are not related to the lack
> or presence of side-effects.

With side effects it does matter when the argument (or various parts
of it) will be evaluated, and if it will be evaluated at all. The
language will probably promise to evaluate some expressions even if
their value is not needed, e.g. unused function arguments, or it will
be hard to use for people used to side effecting programming.

When you pass or return a function using our local variables, it is
not clear whether it should remember their addresses or values if
the values will later change.

To optimize a tail call you have to be sure that the function will
not remember the addresses of local variables somewhere outside,
or the "optimization" changes the semantics of legal programs.

The programmer has to ensure that the compiler has chosen the way he
wanted, he has more things to care about, so even if it is possible
to use some of these constructs, they involve more complication, may
require explicit treatment etc.

In a pure functional language lazy evaluation is natural, because
it doesn't change the semantics except of causing some programs
to terminate (it may require more or less memory and run slower or
faster).

In perl there is a difference between passing 5 and passing a function
returning 5 (and between using such value and teh value returned by
such function), in Haskell there is not. Lazy evaluation in some
sense contains the idea of unifying values with nullary functions
returning them. It's fun that && is like other operators and that
you may emulate the case statement with indexing of an array, not
worrying about unnecessary evaluation of its unused elements.

Quote:
> And I'm not sure it's correct to say that you "gain" optimizations.

You gain the ability to perform some optimizations by the translator.
Right, you don't automatically gain the optimizations.

--

 \__/          GCS/M d- s+:-- a22 C+++>+++$ UL++>++++$ P+++ L++>++++$ E-
  ^^                W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP->+ t
QRCZAK                  5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-



Sat, 01 Dec 2001 03:00:00 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. Negation nomenclature

2. several Qs

3. Qs on CLUBMGR, Template BUG ???

4. Qs

5. New newbies Qs on Ruby

6. Newbie Qs: startup time, Module.constants, chdir, Ruby distro's library

7. Qs on Ruby and DbC/Smalltalk

8. 2 Qs: IndexedFaceSets & browsers

9. Qs re 'Write & 'Read

10. newbie obj files Qs

11. NASM Qs

12. Newbie Pmode Qs

 

 
Powered by phpBB® Forum Software