Check for redundancy

Check for redundancy

[Andreas Röhler]

Hi,

is there a check for redundancy in code?

Byte-compile warnings seem not to cover this.

Thanks,

Andreas

RE: Check for redundancy

[Drew Adams]

> is there a check for redundancy in code?
> Byte-compile warnings seem not to cover this.

I don't have an answer.  But maybe start by defining "redundancy".
Do you mean more than one definition of something in a file?
A function? variable? macro?

Re: Check for redundancy

[Andreas Röhler]

Am 24.06.2015 um 15:23 schrieb Drew Adams:
>> is there a check for redundancy in code?
>> Byte-compile warnings seem not to cover this.
> I don't have an answer.  But maybe start by defining "redundancy".
> Do you mean more than one definition of something in a file?
> A function? variable? macro?

The term is not specific to programming: expressing things which have 
been expressed already.
Human language needs it, as we may not grasp the meaning at first time, 
also repeating contributs to sense sometimes.

WRT to programming: for example two or more  functions taking the same 
kind of arguments, producing the same result but are named differently 
and reside at different places in code.

Given these code is designed to be processed at same time and location, 
that would be redundant.

Pertains to all kind of definitions.

Re: Check for redundancy

[Stefan Monnier]

> The term is not specific to programming: expressing things which have been
> expressed already.

Obviously, Drew knows that.  The issue is that if you want to check for
redundancy in code, it's presumably by doing it with another piece of
code.  That other piece of code will have to encode formally what you
mean by redundancy, so to be able to write it, you'll need to describe
formally what you mean by redundancy.  And that's pretty damn hard for
the usual interesting cases of redundancy.

Of course, you could also use machine-learning to define "redundancy" by
way of a set of examples used to train your machine-learning code.
Not sure how well it would work, nor how to make it work well.




        Stefan

Re: Check for redundancy

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Jun 24, 2015 at 02:21:03PM -0400, Stefan Monnier wrote:
> > The term is not specific to programming: expressing things which have been
> > expressed already.
> 
> Obviously, Drew knows that.  The issue is that if you want to check for
> redundancy in code, it's presumably by doing it with another piece of
> code [...]

To throw an unorthodox idea into the air, one could measure the compression
ratio (e.g. with gzip) and relate it to the compression ratio of "known
good" code (I know, I know... :-)

- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlWLHNkACgkQBcgs9XrR2ka1MACeKYaTDS3aNmfwnO2JSYAVmXKx
qfMAnj5A+eSEkW0UNdALNolFk1CoEIUc
=6Zpf
-----END PGP SIGNATURE-----

Re: Check for redundancy

[Stefan Monnier]

> To throw an unorthodox idea into the air, one could measure the compression
> ratio (e.g. with gzip) and relate it to the compression ratio of "known
> good" code (I know, I know... :-)

Compressing a file does give you some information about the amount of
redundancy in that code, but that might not be the redundancy you care
about (e.g. using longer identifiers will give you higher compression
ratios, but that's usually not what's considered "redundancy in code").
Also, it's not immediately clear how to go from this to finding the
actual redundancy.


        Stefan

Re: Check for redundancy

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Jun 24, 2015 at 11:23:41PM -0400, Stefan Monnier wrote:
> > To throw an unorthodox idea into the air, one could measure the compression
> > ratio (e.g. with gzip) and relate it to the compression ratio of "known
> > good" code (I know, I know... :-)
> 
> Compressing a file does give you some information about the amount of
> redundancy in that code, but that might not be the redundancy you care
> about (e.g. using longer identifiers will give you higher compression
> ratios, but that's usually not what's considered "redundancy in code").
> Also, it's not immediately clear how to go from this to finding the
> actual redundancy.

Yeah -- the thing was a bit tongue-in-cheek. Much of the redundancy is
(as you noted) in the eye of the beholder, and this is what makes this
discussion "interesting". You'd have to keep (as you say) the variable
names out of the equation (or do you? *I* for one consider "hungarian
notation" highly redundant -- let the type system cope with that,
others may not).

That said, I have seen this rough measure (gzip compression ratio) used
as a rough "similarity measure": compress each file separately, slap
both together and compress, and watch the reduction.

For a first step in exploratory work, just to learn what one really
wants to put into the term "redundancy you care about" it might
be useful.

regards
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlWLsh0ACgkQBcgs9XrR2kZDVwCfRyAPGKBVFtkWrm1BapWAPqcd
q4AAnRe8hLtPYhLzesXveBuvcJcDlolj
=YpFU
-----END PGP SIGNATURE-----

Re: Check for redundancy

[Emanuel Berg]

tomas@tuxteam.de writes:

> *I* for one consider "hungarian notation" highly
> redundant -- let the type system cope with that,
> others may not).

Hungarian notation is a joke. The whole idea with high
level code is that you shouldn't think about that.
Now HN is only in systems like Visual Basic and M$
Access because they come with WYSIWYG GUI builders
which typically produce one million objects with
similar names. So to get to the properties of one such
object you'd start with the type (e.g., button) to
limit the set of object in your "search". Ah! I get
angry just by thinking about it.

> That said, I have seen this rough measure (gzip
> compression ratio) used as a rough "similarity
> measure": compress each file separately, slap both
> together and compress, and watch the reduction.

How about just compressing the entire source and make
a quota of the decrease in size? Those algorithms work
on recurring patterns being replaced by something
much shorter indicating the occurence of the pattern.
If there isn't anything recurring it can't be
compressed. So if it is totally factored up then it
can only be "literally" compressed, and not in terms
of the code logic, which should be much less for a big
project. Right? I don't know. Next time I'm here I'll
test this on some of my favorite software...

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Check for redundancy

[Marcin Borkowski]

On 2015-06-26, at 17:01, Emanuel Berg <embe8573@student.uu.se> wrote:

> Hungarian notation is a joke. [...]

I would bet that you've never done anything in LaTeX3, have you?

I agree that for high-level, general-purpose languages, HN is rarely
a good idea.  (Though some variants, like consistent naming schemes -
like Emacs' convention for variables ending in ‘-function’ or ‘-hook’ -
are fine, aren’t they?)

For a fairly low-level thing like TeX, in which the same thing can be
represented in a few ways (like “\foo” versus “foo”, which is a bit like
the symbol/string difference in Lisp), you would perish without it.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Check for redundancy

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

> I agree that for high-level, general-purpose
> languages, HN is rarely a good idea. (Though some
> variants, like consistent naming schemes - like
> Emacs' convention for variables ending in
> ‘-function’ or ‘-hook’ - are fine, aren’t they?)

I never used -function but -hook is good because then
you can often know the name of a hook by putting the
pieces together. They are also good for searching
which is the same reason for them being useful in
those hideous GUI makers. Yes, that is interesting.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Check for redundancy

[Robert Thorpe]

Marcin Borkowski <mbork@mbork.pl> writes:

> On 2015-06-26, at 17:01, Emanuel Berg <embe8573@student.uu.se> wrote:
>
>> Hungarian notation is a joke. [...]
>
> I would bet that you've never done anything in LaTeX3, have you?
>
> I agree that for high-level, general-purpose languages, HN is rarely
> a good idea.  (Though some variants, like consistent naming schemes -
> like Emacs' convention for variables ending in ‘-function’ or ‘-hook’ -
> are fine, aren’t they?)
>
> For a fairly low-level thing like TeX, in which the same thing can be
> represented in a few ways (like “\foo” versus “foo”, which is a bit like
> the symbol/string difference in Lisp), you would perish without it.

I agree, it has it's uses.

Hungarian notation was used a lot in early programs using the MS Windows API.
In that API there are quite a few situations where you want to hold the
same value in two different ways.  E.g. you want a "thing" and "handle
to a thing".  Also, there aren't as many types as there should be.  This
makes Hungarian notation useful when dealing with the API.  It can be
useful when dealing with GUI generators, but that's secondary.

That said, that's a weakness of the API.  Also, it's not useful when
you're inside the guts of your own programming.  That makes it hard to
figure out when to switch from hungarian notation back to normal naming.

BR,
Robert Thorpe

Re: Check for redundancy

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Jun 27, 2015 at 01:11:49PM +0100, Robert Thorpe wrote:
> Marcin Borkowski <mbork@mbork.pl> writes:
> 
> > On 2015-06-26, at 17:01, Emanuel Berg <embe8573@student.uu.se> wrote:
> >
> >> Hungarian notation is a joke. [...]

[...]

> Hungarian notation was used a lot in early programs using the MS Windows API.

AFAIR (yes, I'm an old fart) Hungarian notation was introduced at Microsoft
(by Charles Simonyi, no less) because their C compiler was abysmal at type
checking.

Yes, the API sucked too. Possibly it still sucks (since times Windows 3.1
I haven't had to look at it, thanfully)

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlWOoTsACgkQBcgs9XrR2kal3wCdEz0M5yIGH4Kyq2KcwA+FoIP6
5R4An1de14dAcDxOEZBhL8X0dF0imZiL
=/Vdq
-----END PGP SIGNATURE-----

Re: Check for redundancy

[Emanuel Berg]

<tomas@tuxteam.de> writes:

> AFAIR (yes, I'm an old fart) Hungarian notation was
> introduced at Microsoft (by Charles Simonyi, no
> less) because their C compiler was abysmal at
> type checking.

There is some material on it in this book:

    @book{programmers-at-work,
      title      = {Programmers at Work},
      author     = {Susan Lammers},
      publisher  = {Tempus Books},
      year       = 1989,
      ISBN       = 1556152116
    }

> Yes, the API sucked too. Possibly it still sucks
> (since times Windows 3.1 I haven't had to look at
> it, thanfully)

Yeah, I suspect it is (was) there for some reason.
It has to be real bad for it to help tho :) Here is
the Wikipedia article [1] - especially read the
"Notable opinions" section!

The best one:

  * Linus Torvalds:

        Encoding the type of a function into the name
        (so-called Hungarian notation) is brain
        damaged — the compiler knows the types anyway
        and can check those, and it only confuses
        the programmer.

The second-best one:

  * Bjarne Stroustrup:

        ... I don't recommend 'Hungarian'. I regard
        'Hungarian' (embedding an abbreviated version
        of a type in a variable name) a technique that
        can be useful in untyped languages, but is
        completely unsuitable for a language that
        supports generic programming and
        object-oriented programming — both of which
        emphasize selection of operations based on the
        type and arguments (known to the language or
        to the run-time support). In this case,
        'building the type of an object into names'
        simply complicates and minimizes abstraction.

[1] https://en.wikipedia.org/wiki/Hungarian_notation

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Check for redundancy

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Jun 28, 2015 at 01:02:21AM +0200, Emanuel Berg wrote:
> <tomas@tuxteam.de> writes:
> 
> > AFAIR (yes, I'm an old fart) Hungarian notation was
> > introduced at Microsoft (by Charles Simonyi, no
> > less) because their C compiler was abysmal at
> > type checking.
> 
> There is some material on it in this book:
> 
>     @book{programmers-at-work,
[...]

Thanks for the ref!

> [...] Here is
> the Wikipedia article [1] - especially read the
> "Notable opinions" section!

and for reminding me of this one. I'd even go further than Stroustroup:
if you have an untyped language, Hungarian is a losing proposition.
The type "tags" in the var names are now possibly lying to you, which
is even worse. IMHO better you embrace the untyped language and come up
with more intelligent techniques [1] (or, if that's not your thing, you
just change languages).

[1] Lint, why not?

- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlWP1XQACgkQBcgs9XrR2kbnfQCfaN6HZqqU0LzuMQeTlpmNfgAR
zZAAn2z1pXLRqhHX6QxHtecAIQyD5wdd
=xf95
-----END PGP SIGNATURE-----

Re: Check for redundancy

[Emanuel Berg]

<tomas@tuxteam.de> writes:

> and for reminding me of this one. I'd even go
> further than Stroustroup: if you have an untyped
> language, Hungarian is a losing proposition.
> The type "tags" in the var names are now possibly
> lying to you, which is even worse. IMHO better you
> embrace the untyped language and come up with more
> intelligent techniques [1] (or, if that's not your
> thing, you just change languages).

Indeed. For untyped languages, why put the types in
code where they aren't actually types anyway? And for
typed languages, why put them in code where they still
aren't types and even more, where they can indicate
the *incorrect* type as well?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Check for redundancy

[Yuri Khan]

On Sun, Jun 28, 2015 at 9:50 PM, Emanuel Berg <embe8573@student.uu.se> wrote:
> <tomas@tuxteam.de> writes:
>
> Indeed. For untyped languages, why put the types in
> code where they aren't actually types anyway? And for
> typed languages, why put them in code where they still
> aren't types and even more, where they can indicate
> the *incorrect* type as well?

There are still reasons to use Hungarian notation, because even the
most strongly typed languages in common use are not strongly typed
enough. (Haskell is or can be persuaded to be, but my employer is not
ready to embrace Haskell.)

1: Every time I have to work with two or more coordinate systems that
use the same axis names (typically X and Y). E.g. a mathematical plane
and pixel coordinates relative to a window and/or a monitor and/or a
workspace. Eventually I start naming variables starting with “wx, wy”
for window, “sx, sy” for screen, etc.

2: Strings in different encodings. E.g. the Python (2.7) web framework
I use gives me Unicode strings, then I want to map them to filenames
and thus have to encode them to UTF-8, and later I need to send an
urlencoded header to the web server. Pretty soon Unicode strings get
the u_ prefix, UTF-8 strings get u8_, filenames from the user-provided
zip file (that are labeled in the zip file directory as cp437, but
actually are windows-1251 in most of my cases, but I can’t rely on
that and have to implement a heuristic) get yet another prefix.

3: Local and UTC times, if you are unfortunate to have to deal with them.

4: Measurements that are in neither SI nor common use units. (A
routing algorithm I used to work with had a parameter expressing the
estimated pedestrian speed. It typically had a value of 56. The unit?
Centimeters per second, of course. The common speed unit is km/h
here.)

Without carefully labeling each affected variable, after a month of
not touching the codebase, it becomes impossible to make modifications
without breaking anything.

Note that this isn’t the Systems Hungarian many people are used to,
which encodes the actual type. It’s Applications Hungarian, where
variables that have the same physical type get different prefixes
after their conceptual type.

Re: Check for redundancy

[Emanuel Berg]

Yuri Khan <yuri.v.khan@gmail.com> writes:

> There are still reasons to use Hungarian notation,
> because even the most strongly typed languages in
> common use are not strongly typed enough. (Haskell
> is or can be persuaded to be, but my employer is not
> ready to embrace Haskell.)

Good call :)

> 1: Every time I have to work with two or more
> coordinate systems that use the same axis names
> (typically X and Y). E.g. a mathematical plane and
> pixel coordinates relative to a window and/or
> a monitor and/or a workspace. Eventually I start
> naming variables starting with “wx, wy” for window,
> “sx, sy” for screen, etc.

Yes, however that falls outside of my definition of
Hungarian notation - I would do the same, only I would
probably spell out "window", "screen", and so on.
So in Lisp it would be window-x, window-y; in C,
win_x, win_y; in C++ perhaps Window would be
a class; etc.

> Without carefully labeling each affected variable,
> after a month of not touching the codebase, it
> becomes impossible to make modifications without
> breaking anything.

Indeed, I do long and descriptive names to the best of
my ability. I consider it a virtue. In C, when you
don't do that typically, I still do them longer and
more descriptive than most C programmers.

> Note that this isn’t the Systems Hungarian many
> people are used to, which encodes the actual type.
> It’s Applications Hungarian, where variables that
> have the same physical type get different prefixes
> after their conceptual type.

In so many words, I agree. Tho to my mind this is
common sense rather than any particular notational
system being adhered to.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Check for redundancy

[Robert Thorpe]

Emanuel Berg <embe8573@student.uu.se> writes:

> <tomas@tuxteam.de> writes:
...
> Indeed. For untyped languages, why put the types in
> code where they aren't actually types anyway?

Just because there aren't types doesn't mean that variables don't have
types.  What "untyped" means is that the language doesn't enforce typing
for you.  That makes it more important that you manage them carefully
for yourself.

> And for
> typed languages, why put them in code where they still
> aren't types and even more, where they can indicate
> the *incorrect* type as well?

As I said, one reason can be: because the framework or library you're
using doesn't use the type system fully.  That's the situation with the
MS Windows interfaces.

I agree with Yuri Khan that it's useful in other situations.  Khan's
examples depend on how broadly you treat the word "type".  Khan is
treating things as types that you don't think of as types, his
definition is a bit broader than yours.  There are arguments for both
ways of looking at things.

Another thing that it's useful for is differentiating a type from
instances of a type.  For example, many people use "something_t" as the
type and "something" as the instance.  I prefer to be more specific,
e.g.: "something_s" for a struct and "something_e" for an enum.

BR,
Robert Thorpe

Re: Check for redundancy

[Emanuel Berg]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

> Just because there aren't types doesn't mean that
> variables don't have types. What "untyped" means is
> that the language doesn't enforce typing for you.
> That makes it more important that you manage them
> carefully for yourself.

... are you sure?

In C, you do

    int five = 5;

In Lisp (Elisp), you do

    (let ((five 5)) ...)

If you want to, you can do (integerp five) but there
is seldom a reason to do that unless you are into
verifying indata. In my experience, you don't have to
do that because such errors will implicitly be brought
to day all but instantly when data is put to use.

Only cool use of such "type" checks are DWIM functions
where you can pass say either a char or a string and
it will put it together differently but produce
a consistent (transparent) result. Note that if those
args were explicitly typed, or HN-typed, that would
not work (unless some HN notion for char-or-string was
invented).

Maybe the variables values have types at runtime but
not necessarily the variable *names* at coding time,
which is when you'd prepend the HN-designation.

In C, tho typing is explicit at declaration, which
would seemingly hand over the responsibility to the
compiler, there is still incomparably more mucking
around with types - explicit and implicit casts,
(void) pointers - typically on first compilation you
get a bunch of this kind of errors (and warnings), all
about types many panes ahead!

So in this case it is the other way around - in C,
having types explicit doesn't reduce "type work", but
instead it is there tenfold, while in Lisp, not
bothering with that makes for not having to do any
of that.

Besides, I don't think of (integerp five) as checking
the "type" in a compiler sense, I think of it as
checking what's there in a human sense much like
looking into a bucket to see what's there so to decide
what to do with it.

> I agree with Yuri Khan that it's useful in other
> situations. Khan's examples depend on how broadly
> you treat the word "type". Khan is treating things
> as types that you don't think of as types, his
> definition is a bit broader than yours. There are
> arguments for both ways of looking at things.
>
> Another thing that it's useful for is
> differentiating a type from instances of a type.
> For example, many people use "something_t" as the
> type and "something" as the instance. I prefer to be
> more specific, e.g.: "something_s" for a struct and
> "something_e" for an enum.

Yeah, I think there is a misunderstanding where you
think I say you cannot mention types, encodings,
units, etc. ever in variable names, i.e. you should
never name something in terms of technology.
That isn't so; I agree there are such cases when that
is called for.

However, the way I understood HN is that you should
*always* use prefixes like that. What I remembered it
looked like this:

    intMoney = 0;
    strGreeting = "Stay a while, and listen!";

And I don't see any reason to do that.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Check for redundancy

[Robert Thorpe]

Emanuel Berg <embe8573@student.uu.se> writes:

> Robert Thorpe <rt@robertthorpeconsulting.com> writes:
>> Just because there aren't types doesn't mean that
>> variables don't have types. What "untyped" means is
>> that the language doesn't enforce typing for you.
>> That makes it more important that you manage them
>> carefully for yourself.
>
> ... are you sure?
>
> In C, you do
>
>     int five = 5;
>
> In Lisp (Elisp), you do
>
>     (let ((five 5)) ...)

I don't understand what this has to do with the issue.  Both of the
languages here have types.  C has static types and Lisp has latent (or
dynamic) types.

What about assembly language?  What about other languages with no type
system or a very limited type system?

> If you want to, you can do (integerp five)

In Lisp the type of a variable is stored with the variable at runtime.
In C the type of a variable is recorded and enforced at compile time.
In many Assembly languages neither are done.  You can't ask the variable
what it's type is and you can't ask the compiler either.  The only
record is in your program and in your mind.

> Yeah, I think there is a misunderstanding where you
> think I say you cannot mention types, encodings,
> units, etc. ever in variable names, i.e. you should
> never name something in terms of technology.
> That isn't so; I agree there are such cases when that
> is called for.

In that case I don't think our opinions about this differ too much.

> However, the way I understood HN is that you should
> *always* use prefixes like that. What I remembered it
> looked like this:
>
>     intMoney = 0;
>     strGreeting = "Stay a while, and listen!";
>
> And I don't see any reason to do that.

It's useful in assembly language programming.

It's also useful in MS Window programming where everything is some kind
of handle.  Even then though, I would only use it for the user
interface, not every variable as you say.

BR,
Rob

Re: Check for redundancy

[Yuri Khan]

On Fri, Jul 3, 2015 at 5:37 AM, Robert Thorpe
<rt@robertthorpeconsulting.com> wrote:

> It's also useful in MS Window programming where everything is some kind
> of handle.  Even then though, I would only use it for the user
> interface, not every variable as you say.

In early Windows programming, all handles were just void*, which made
them all seemingly different for the programmer and identical to the
compiler.

Nowadays (since ≈2002?) the SDK defines a strict mode, where different
kinds of handles become pointers to different tag structure types:

struct tagWND;  // declared but not defined
typedef struct tagWND* HWND;

With a sufficiently strongly typed language and compiler, the
programmer is protected against accidentally using a HWND as a
HBITMAP.

Re: Check for redundancy

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Fri, 3 Jul 2015 09:36:13 +0600
> Cc: "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>,
> 	Emanuel Berg <embe8573@student.uu.se>
> 
> Nowadays (since ≈2002?) the SDK defines a strict mode, where different
> kinds of handles become pointers to different tag structure types:
> 
> struct tagWND;  // declared but not defined
> typedef struct tagWND* HWND;

Perhaps in MSVC compiler, not in MinGW.  With MinGW, something similar
happens only if you compile with -DSTRICT (which is rarely, if ever,
done).  And even in MSVC headers I see something significantly
different from what you show above, and it's also conditioned by
STRICT being defined.

Of course, the original claim that "everything is some kind of handle"
in Windows programming, is also very inaccurate.  Windows headers are
replete with structures, unions, and primitive data types other than
HANDLE.

Re: Check for redundancy

[Yuri Khan]

On Fri, Jul 3, 2015 at 12:41 PM, Eli Zaretskii <eliz@gnu.org> wrote:

>> Nowadays (since ≈2002?) the SDK defines a strict mode, where different
>> kinds of handles become pointers to different tag structure types:
>>
>> struct tagWND;  // declared but not defined
>> typedef struct tagWND* HWND;
>
> Perhaps in MSVC compiler, not in MinGW.  With MinGW, something similar
> happens only if you compile with -DSTRICT (which is rarely, if ever,
> done).  And even in MSVC headers I see something significantly
> different from what you show above, and it's also conditioned by
> STRICT being defined.

Yes. -DSTRICT has been the default setting for new projects created in
MSVC++ since version 7 or so. Is there some problem enabling STRICT on
MinGW, or a reason why it is done rarely?

How is it significantly different? Here’s what I see in some ancient copy:

// in winnt.h
#ifdef STRICT
typedef void *HANDLE;
#define DECLARE_HANDLE(name) struct name##__ { int unused; }; typedef
struct name##__ *name
#else
typedef PVOID HANDLE;
#define DECLARE_HANDLE(name) typedef HANDLE name
#endif

// in windef.h
DECLARE_HANDLE            (HWND);
DECLARE_HANDLE            (HHOOK);

OK, it’s not an undefined struct, it’s a struct with a unique type
name and a single unused int field. This does not affect the type
system, as neither C nor C++ have structural typing. Leaving the
struct undefined would probably be a bit safer.

Re: Check for redundancy

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Fri, 3 Jul 2015 17:48:28 +0600
> Cc: "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
> 
> Yes. -DSTRICT has been the default setting for new projects created in
> MSVC++ since version 7 or so. Is there some problem enabling STRICT on
> MinGW, or a reason why it is done rarely?

I have no idea, and this isn't the place to discuss these issues
anyway.

(Personally, I see no good reasons for doing that, and I'm quite sure
it will break some legitimate code.)

Re: Check for redundancy

[Robert Thorpe]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Yuri Khan <yuri.v.khan@gmail.com>
>> Date: Fri, 3 Jul 2015 17:48:28 +0600
>> Cc: "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
>> 
>> Yes. -DSTRICT has been the default setting for new projects created in
>> MSVC++ since version 7 or so. Is there some problem enabling STRICT on
>> MinGW, or a reason why it is done rarely?
...

> (Personally, I see no good reasons for doing that, and I'm quite sure
> it will break some legitimate code.)

As Eli says this is help-gnu-emacs, so talking about the peculiarities
of MS Windows is off-topic.

I'll just say this much more about it....  I was giving the old Windows
interfaces as an example of where Hungarian Notation can be useful even
though the language has types.  If Microsoft have finally fixed it in
MSVC then that's great for people using MSVC.  It still shows that the
problem can happen.  It may not help old programs though, and the
classic Windows interface is mostly for old programs.  In the past
programmers often wouldn't cast handles correctly.  Sometimes variables
were declared with HANDLE.  It will help old programs that were written
carefully.

I agree with the criticisms Eli Zaretski, Rusi and Pascal Bourguignon
made of what I wrote.  I was trying to make things simple.  I could have
been more precise and kept things simple.

BR,
Robert Thorpe

Re: Check for redundancy

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Jul 03, 2015 at 12:37:42AM +0100, Robert Thorpe wrote:
> Emanuel Berg <embe8573@student.uu.se> writes:

[...]

> In Lisp the type of a variable is stored with the variable at runtime.

Let me nit a pick: In Lisp it's not the variable which "has" a type,
but the value itself. It's the 5 currently "living" in five which is
an int.

- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlWWJwwACgkQBcgs9XrR2ka4agCffKVM7DmJb8jSy+L3e56g8oSq
9ZgAnA3MzRqKpSKXkCQxhCYEEv3ywHCR
=unCb
-----END PGP SIGNATURE-----

Re: Check for redundancy

[Emanuel Berg]

<tomas@tuxteam.de> writes:

> On Fri, Jul 03, 2015 at 12:37:42AM +0100, Robert
> Thorpe wrote:
>
>> Emanuel Berg <embe8573@student.uu.se> writes:
>
> [...]
>
>> In Lisp the type of a variable is stored with the
>> variable at runtime.
>
> Let me nit a pick: In Lisp it's not the variable
> which "has" a type, but the value itself. It's the 5
> currently "living" in five which is an int.

I don't know who said that which you are quoting, but
what you said is what I said.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Check for redundancy

[Rusi]

On Friday, July 3, 2015 at 11:40:04 AM UTC+5:30, to...@tuxteam.de wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Fri, Jul 03, 2015 at 12:37:42AM +0100, Robert Thorpe wrote:
> > Emanuel Berg  writes:
> 
> [...]
> 
> > In Lisp the type of a variable is stored with the variable at runtime.
> 
> Let me nit a pick: 

And let me pick a nit with your "nit a pick": Its pick a nit not nit a pick <wink>

> In Lisp it's not the variable which "has" a type,
> but the value itself. It's the 5 currently "living" in five which is
> an int.

Re: Check for redundancy

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Jul 02, 2015 at 11:38:43PM -0700, Rusi wrote:
> And let me pick a nit with your "nit a pick": Its pick a nit not nit a pick <wink>

;-)

- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlWWP7YACgkQBcgs9XrR2kZ66QCfRyFUqgLnecEq8ZdImfW/wZFy
7WwAn1657cMNxu/VWCmVpa9KXSj+gm0R
=OGV9
-----END PGP SIGNATURE-----

Re: Check for redundancy

[Loris Bennett]

Rusi <rustompmody@gmail.com> writes:

>> Let me nit a pick: 
>
> And let me pick a nit with your "nit a pick": Its pick a nit not nit a pick <wink>

Let me pick a nit with your nit-a-pick-nitpick: It's "it's" and not "its".

Cheers,

Loris

-- 
This signature is currently under construction.

Re: Check for redundancy

[Emanuel Berg]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> The term is not specific to programming: expressing
>> things which have been expressed already.
>
> Obviously, Drew knows that. The issue is that if you
> want to check for redundancy in code, it's
> presumably by doing it with another piece of code.
> That other piece of code will have to encode
> formally what you mean by redundancy, so to be able
> to write it, you'll need to describe formally what
> you mean by redundancy. And that's pretty damn hard
> for the usual interesting cases of redundancy.

Yeah, this is extremely difficult to accomplish at any
level and to get it to be actually useful in practice
is close to impossible. And it is not needed.

> Of course, you could also use machine-learning to
> define "redundancy" by way of a set of examples used
> to train your machine-learning code. Not sure how
> well it would work, nor how to make it work well.

I dare say the AI methods will *never* be able to
do this!

The only method that might work is to have a compiler
do relentless super-optimization over and over. Then,
when done, tho having different codes, some functions
will have produced the same sequence of machine
instructions - then, you could delete one of them,
sound and safe.

No - the much better way is:

    1) Write and read code every day. You will learn
       to identify what isn't needed.

    2) Don't be afraid of doing stuff and having stuff
       around. Your computer isn't a garage that can
       fill up with junk. There is no harm in having
       a couple of defuns and shell functions lying
       around, mostly up to no good, some of them
       doing (almost) the same thing as their
       neighbor. This is not a situation to be
       worried about. It is not a bloated system or
       a system that will run slower. Instead of
       thinking you "have" to merge them into one
       thing that does everything "the right way"
       think what other functions you *don't* have and
       that you would like, and focus on those.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Check for redundancy

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> The term is not specific to programming: expressing things which have been
>> expressed already.
>
> Obviously, Drew knows that.  The issue is that if you want to check for
> redundancy in code, it's presumably by doing it with another piece of
> code.  That other piece of code will have to encode formally what you
> mean by redundancy, so to be able to write it, you'll need to describe
> formally what you mean by redundancy.  And that's pretty damn hard for
> the usual interesting cases of redundancy.

A pretty easy (and safe) way is to define redundancy as "functional
equivalence" (which is what the OP mean, I think) and then compare the
generated bytecode. If it is the same, the functions are equivalent.
That doesn't work if different constructs with the same effects (`if' vs
`cond') compile to different bytecode, but that doesn't preclude its
practical usefulness.

C++ compilers do that for template functions, for avoiding code
explosion. Certain C++ compiler does that for ordinary functions as
well.

[snip]

Re: Check for redundancy

[Emanuel Berg]

Óscar Fuentes <ofv@wanadoo.es> writes:

> A pretty easy (and safe) way is to define redundancy
> as "functional equivalence" (which is what the OP
> mean, I think) and then compare the
> generated bytecode.

Have ten programmers solve the same problem, then
compile - do you now have ten instances of identical
bytecode? I don't think so.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Check for redundancy

[Óscar Fuentes]

Emanuel Berg <embe8573@student.uu.se> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> A pretty easy (and safe) way is to define redundancy
>> as "functional equivalence" (which is what the OP
>> mean, I think) and then compare the
>> generated bytecode.
>
> Have ten programmers solve the same problem, then
> compile - do you now have ten instances of identical
> bytecode? I don't think so.

See all those tiny helper functions defined in every package. They do
the same and I guess that they are implemented the same way. An
informative note from the byte compiler saying that
foo-remove-string-prefix has an equivalent available on the current
version of Emacs would be appreaciated.

Solving the general problem is much harder, obviously, but I think that
the OP knows that.

Re: Check for redundancy

[Emanuel Berg]

Óscar Fuentes <ofv@wanadoo.es> writes:

> See all those tiny helper functions defined in every
> package. They do the same and I guess that they are
> implemented the same way.

Yeah, good point. Start small.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Check for redundancy

[Stefan Nobis]

Emanuel Berg <embe8573@student.uu.se> writes:

[want to check for redundancy in code]
> Yeah, this is extremely difficult to accomplish at any
> level and to get it to be actually useful in practice
> is close to impossible. And it is not needed.

Hmmm... at least for some people it seems important enough:

https://www.devexpress.com/Products/CodeRush/duplicate_code.xml

CodeRush is a (commercial) plugin for Microsoft Visual Studio and it
has some redundancy detection and removing abilities built in. I only
played a little bit with it and it is indeed quite impressing and
disappointing at the same time. Nevertheless, I think at least for
junior programmers it might have some value (and for programmers in
the industry with a high time pressure; its helpful to refactor
redundancies with just a press of a button and adding some new names).

> I dare say the AI methods will *never* be able to do this!

AI methods today are even able to identify important and influential
paintings in the history of art:

http://www.technologyreview.com/view/538281/machine-vision-algorithm-chooses-the-most-creative-paintings-in-history/

Detecting patterns is one of the strong areas of machine learning and
redundancy is a pattern. I would assume that AI methods will at least
someday be quite good at it.

-- 
Stefan.

Re: Check for redundancy

[Andreas Röhler]

Am 25.06.2015 um 09:43 schrieb Stefan Nobis:
> Emanuel Berg <embe8573@student.uu.se> writes:
>
> [want to check for redundancy in code]
>> Yeah, this is extremely difficult to accomplish at any
>> level and to get it to be actually useful in practice
>> is close to impossible. And it is not needed.
> Hmmm... at least for some people it seems important enough:
>
> https://www.devexpress.com/Products/CodeRush/duplicate_code.xml
>
> CodeRush is a (commercial) plugin for Microsoft Visual Studio and it
> has some redundancy detection and removing abilities built in. I only
> played a little bit with it and it is indeed quite impressing and
> disappointing at the same time. Nevertheless, I think at least for
> junior programmers it might have some value (and for programmers in
> the industry with a high time pressure; its helpful to refactor
> redundancies with just a press of a button and adding some new names).
>
>> I dare say the AI methods will *never* be able to do this!
> AI methods today are even able to identify important and influential
> paintings in the history of art:
>
> http://www.technologyreview.com/view/538281/machine-vision-algorithm-chooses-the-most-creative-paintings-in-history/
>
> Detecting patterns is one of the strong areas of machine learning and
> redundancy is a pattern. I would assume that AI methods will at least
> someday be quite good at it.
>

Avoiding redundancy is important as it saves time. Assume there is a bug 
in some redundant: fixing this  would leave the other bug at place.

But it's not about bugs only. Functions might be shaped more or less 
efficient in various regards.
When optimizing a redundant function, second range quality will remain.

Re: Check for redundancy

[Emanuel Berg]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:

> Avoiding redundancy is important as it saves time.
> Assume there is a bug in some redundant: fixing this
> would leave the other bug at place.
>
> But it's not about bugs only. Functions might be
> shaped more or less efficient in various regards.
> When optimizing a redundant function, second range
> quality will remain.

Yes, if there is a tool to identify those that'd
be great.

Only there are hundreds of thousands of programs and
software components that have been developed without
such and those work just fine.

This tells me this is (would be) one for the toolbox
that can certainly be interesting to try out but it
isn't the new combination key or spoke key.

The most important thing for an aspiring programmer is
still, and will always be, to write code every day, as
much as possible, and as good as possible, and then do
it over and over at a higher and higher level.

Myself I have 281 Elisp defuns. I'm happy to try any
tool that will identify how many of those are in fact
redundant. If say 50 are then I'd start worrying.
I'd change my mind on this. If ten are, I'd be cool.
But I'd fix them nonetheless so yes, it'd be useful,
just not that big a factor.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Check for redundancy

[Emanuel Berg]

Stefan Nobis <snobis@gmx.de> writes:

> at least for some people it seems important enough

No doubt. I'm not in their exact positions (phew) so
I can't tell for sure but it seems I disagree
with them.

> Nevertheless, I think at least for junior
> programmers it might have some value (and for
> programmers in the industry with a high time
> pressure

For junior programmers it doesn't have a value save
for negative perhaps because junior programmers
shouldn't worry and feel disheartened by what they did
yesterday, they should just do new things, today!
If they later on feel like (manually) asserting old
code and make improvements and correct obvious
inefficiencies, that's on the other hand very helpful.

As for people in the industry working with high time
pressure whatever they do will never beat the thing
tons of people worked on, day in and day out, forever.
If they can remove redundancy from then next FPS game
with a movie licence I couldn't care less.

> its helpful to refactor redundancies with just
> a press of a button and adding some new names).

Indeed, the type of redundancy checker that will just
identify identical code blocks (yeah, two lines in
a row will do) - this is not a bad idea.

> Detecting patterns is one of the strong areas of
> machine learning and redundancy is a pattern.
> I would assume that AI methods will at least someday
> be quite good at it.

Is it really that difficult for a computer to do this?
The suggestion to have defuns byte-compiled
individually and then just compare the result sounds
much more straightforward.

Is there a prototype of that machine-learning
pattern-detector one can examine peace and quiet?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Check for redundancy

[Stefan Nobis]

Emanuel Berg <embe8573@student.uu.se> writes:

> Is it really that difficult for a computer to do this?

Depends on the question you ask. :)

IMHO the most interesting part would be to identify similar code
blocks (even using different functions and variables internally), that
can be refactored to a new, more generalized function with apropriate
parameters.

But this "similiarity" is quite difficult. In the general case you
could summarize all your code blocks into one single function and on
the other hand there might be quite some functions that are quite
similiar but should stay separated because this way the intentions are
better expressed and the the code using these function will be more
readable.

Therefore training an AI to produce really helpful recommendations
will be quite difficult, me thinks.

> The suggestion to have defuns byte-compiled individually and then
> just compare the result sounds much more straightforward.

This will give less false positives, but I think it will miss many
opportunities to refactor similar code blocks.

-- 
Stefan.

Re: Check for redundancy

[Emanuel Berg]

Stefan Nobis <snobis@gmx.de> writes:

> IMHO the most interesting part would be to identify
> similar code blocks (even using different functions
> and variables internally), that can be refactored to
> a new, more generalized function with
> apropriate parameters.
>
> But this "similiarity" is quite difficult. In the
> general case you could summarize all your code
> blocks into one single function and on the other
> hand there might be quite some functions that are
> quite similiar but should stay separated because
> this way the intentions are better expressed and the
> the code using these function will be more readable.
>
> Therefore training an AI to produce really helpful
> recommendations will be quite difficult, me thinks.

What I remember from the thrice-accursed textbooks on
AI the standard example was a machine playing
tic-tac-toe on a 3x3 grid (like in the Wargames
movie). To this end they made a physical array of
boxes that each would contain balls of different
colors. This would correspond to the heuristics of
search space traversal, and it would be gradually
refined for each game played. Soon the machine would
play a perfect game. When computers came they put this
into a program and the training consisted of the
program playing against another instance of itself.

This is all cool and well, but I still think it would
be much easier to base this on some base machine
representation. That way, you don't have to worry
about variable and function names as those would be
data and references in registers.

It doesn't have to be a perfect hit! You can have it
suggest here as well. But put it this way: if the
compiler can't put it into nearly the same form after
applying all optimization - either the compiler isn't
that good, or the functions just aren't the same.

I just got and idea - stay tuned...

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Check for redundancy

[Emanuel Berg]

Emanuel Berg <embe8573@student.uu.se> writes:

> I just got and idea - stay tuned...

(defun make-backrefs (total)
  (if (> total 0)
      (format "%s\\\\%s" (make-backrefs (1- total)) total)
    "") )

(defun make-backrefs-while (total)
  (let ((refs ""))
    (while (> total 0)
      (setq refs (format "\\\\%s%s" total refs))
      (cl-decf total) )
    refs) )

(defun make-backrefs-tail (total &optional refs)
  (unless refs (setq refs ""))
  (if (> total 0)
      (make-backrefs-tail (1- total) (format "\\\\%s%s" total refs))
    refs) )

;; test they produce the same output at least :)
(let ((num-refs 5))
  (insert "\n\n")
  (insert ";; " (make-backrefs num-refs)       "\n")
  (insert ";; " (make-backrefs-while num-refs) "\n")
  (insert ";; " (make-backrefs-tail num-refs)  "\n") )

;; \\1\\2\\3\\4\\5
;; \\1\\2\\3\\4\\5
;; \\1\\2\\3\\4\\5

(disassemble (byte-compile 'make-backrefs))

    0       varref    total
    1       constant  0
    2       gtr
    3       goto-if-nil 1
    6       constant  format
    7       constant  "%s\\\\%s"
    8       constant  make-backrefs
    9       varref    total
    10      sub1
    11      call      1
    12      varref    total
    13      call      3
    14      return
    15:1    constant  ""
    16      return

(disassemble (byte-compile 'make-backrefs-while))

    0       constant  ""
    1       varbind   refs
    2       varref    total
    3:1     constant  0
    4       gtr
    5       goto-if-nil 2
    8       constant  format
    9       constant  "\\\\%s%s"
    10      varref    total
    11      varref    refs
    12      call      3
    13      varset    refs
    14      varref    total
    15      sub1
    16      dup
    17      varset    total
    18      goto      1
    21:2    varref    refs
    22      unbind    1
    23      return

(disassemble (byte-compile 'make-backrefs-tail))

    0       varref    refs
    1       goto-if-not-nil 1
    4       constant  ""
    5       varset    refs
    6:1     varref    total
    7       constant  0
    8       gtr
    9       goto-if-nil 2
    12      constant  make-backrefs-tail
    13      varref    total
    14      sub1
    15      constant  format
    16      constant  "\\\\%s%s"
    17      varref    total
    18      varref    refs
    19      call      3
    20      call      2
    21      return
    22:2    varref    refs
    23      return

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Check for redundancy

[Pascal J. Bourguignon]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

> Emanuel Berg <embe8573@student.uu.se> writes:
>
>> Robert Thorpe <rt@robertthorpeconsulting.com> writes:
>>> Just because there aren't types doesn't mean that
>>> variables don't have types. What "untyped" means is
>>> that the language doesn't enforce typing for you.
>>> That makes it more important that you manage them
>>> carefully for yourself.
>>
>> ... are you sure?
>>
>> In C, you do
>>
>>     int five = 5;
>>
>> In Lisp (Elisp), you do
>>
>>     (let ((five 5)) ...)
>
> I don't understand what this has to do with the issue.  Both of the
> languages here have types.  C has static types and Lisp has latent (or
> dynamic) types.

Yes.  And C is weakly typed, while Lisp is strongly typed:

      #include <stdio.h>
      int main(void){
        char a[]="hello"; 
        int b=a+3;
        printf("%d\n",b);
        return 0;
      }
      prints some random garbage such as: -1309384925
      status = 0
 
instead:

      (let* ((a "hello")
             (b (+ a 3)))
        b)
      Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p
                 "hello")

> What about assembly language?  What about other languages with no type
> system or a very limited type system?
>
>> If you want to, you can do (integerp five)
>
> In Lisp the type of a variable is stored with the variable at runtime.

No, never, ever, not in a billion years.

In lisp, types are not associated with variables, but with objects!

There's nothing in the definition of the lisp language that would
prevent this association to be performed at compilation time, in some
cases at least.

When in CL you declare a type naming a variable, what you are  telling
the computer, is that you promise you will never bind to that variable
objects of a different type.  But it's still the objects to which the
type is associated, the objects bound to that variable, not the
variable.


> In C the type of a variable is recorded and enforced at compile time.

Usually.  There's nothing in the C langage definition that prevents
run-time checks.  On the contrary, most type casting are undefined or
have implementation specific behaviors.  For example, check the
restrictions on using the variants of a union.



> In many Assembly languages neither are done.  You can't ask the variable
> what it's type is and you can't ask the compiler either.  The only
> record is in your program and in your mind.

Indeed, there are very few machines that associate type with the objects
(the values).  The only one coming to mind is the lisp machine
processor, but IIRC, there may have been a few other machines with type
tags.


>> However, the way I understood HN is that you should
>> *always* use prefixes like that. What I remembered it
>> looked like this:
>>
>>     intMoney = 0;
>>     strGreeting = "Stay a while, and listen!";
>>
>> And I don't see any reason to do that.
>
> It's useful in assembly language programming.
>
> It's also useful in MS Window programming where everything is some kind
> of handle.  Even then though, I would only use it for the user
> interface, not every variable as you say.

The programmer must control its data flows, and therefore he should have
an idea of what data goes into what variables and parameters.  

A tool useful for newbies is to control the type of those data flow,
since often in a single function,  you will have different types for
different data flows. 

However, assigning compilation-time types or using hungarian notation
has at least one big problem:  this prevent generic programming, by
constraining the types of your data much to early in general,

What if now money is represented by its own class associating the
currency with the amount, and if you live the USA, the origin of the
money along with the required documentation, less the cops forfeit it.
(So you see, it's very important to be able to switch to something of
another type, notably for some users).

    (defun invest (intMoney)
       …)

    (invest (make-money
             :amount 10000 :currency :USD 
             :origin (make-trace
                      :explaination "Got a good salary last month."
                      :source-name "My Employer Com"
                      :source-address "Beyond Infinity Drive, 42\nYunque Bajo, CA92222"
                      :document-url "http://my.employer.com/salaries/myself/2025/oct.xml")))

    BANG! invest expected (why? for no reason!) an integer instead of
    some money.


-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: Check for redundancy

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

>> In Lisp the type of a variable is stored with the
>> variable at runtime.
>
> No, never, ever, not in a billion years.
>
> In lisp, types are not associated with variables,
> but with objects!

Yeah, `integerp' is

    (integerp OBJECT)

    Return t if OBJECT is an integer.

however, I don't think Mr. Thorpe was digging into
that distinction, but rather that Lisp is
"runtime/dynamic/execution typed" (excuses if that
terminology is spoken for, if it isn't it fits) -
i.e., it is not about variable vs. object, it is about
static/code vs. dynamic/execution use of types.

And Pascal J. Bourguignon knows this as well as he
knows the technology - make the correction as you see
fit, only keep it real at the same time.

> However, assigning compilation-time types or using
> hungarian notation has at least one big problem:
> this prevent generic programming, by constraining
> the types of your data much to early in general,

Yes! That's exactly what I said with the DWIM
char/string example.

-- 
underground experts united
http://user.it.uu.se/~embe8573