* Re: Check for redundancy [not found] <mailman.6209.1435880273.904.help-gnu-emacs@gnu.org> @ 2015-07-03 8:40 ` Pascal J. Bourguignon 2015-07-03 20:04 ` Emanuel Berg 0 siblings, 1 reply; 44+ messages in thread From: Pascal J. Bourguignon @ 2015-07-03 8:40 UTC (permalink / raw) To: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-07-03 8:40 ` Check for redundancy Pascal J. Bourguignon @ 2015-07-03 20:04 ` Emanuel Berg 0 siblings, 0 replies; 44+ messages in thread From: Emanuel Berg @ 2015-07-03 20:04 UTC (permalink / raw) To: help-gnu-emacs "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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Check for redundancy @ 2015-06-24 9:29 Andreas Röhler 2015-06-24 13:23 ` Drew Adams 0 siblings, 1 reply; 44+ messages in thread From: Andreas Röhler @ 2015-06-24 9:29 UTC (permalink / raw) To: help-gnu-emacs Hi, is there a check for redundancy in code? Byte-compile warnings seem not to cover this. Thanks, Andreas ^ permalink raw reply [flat|nested] 44+ messages in thread
* RE: Check for redundancy 2015-06-24 9:29 Andreas Röhler @ 2015-06-24 13:23 ` Drew Adams 2015-06-24 14:55 ` Andreas Röhler [not found] ` <mailman.5580.1435157733.904.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 44+ messages in thread From: Drew Adams @ 2015-06-24 13:23 UTC (permalink / raw) To: Andreas Röhler, help-gnu-emacs > 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? ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-06-24 13:23 ` Drew Adams @ 2015-06-24 14:55 ` Andreas Röhler [not found] ` <mailman.5580.1435157733.904.help-gnu-emacs@gnu.org> 1 sibling, 0 replies; 44+ messages in thread From: Andreas Röhler @ 2015-06-24 14:55 UTC (permalink / raw) To: Drew Adams, help-gnu-emacs 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
[parent not found: <mailman.5580.1435157733.904.help-gnu-emacs@gnu.org>]
* Re: Check for redundancy [not found] ` <mailman.5580.1435157733.904.help-gnu-emacs@gnu.org> @ 2015-06-24 18:21 ` Stefan Monnier 2015-06-24 21:10 ` tomas ` (3 more replies) 0 siblings, 4 replies; 44+ messages in thread From: Stefan Monnier @ 2015-06-24 18:21 UTC (permalink / raw) To: help-gnu-emacs > 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-06-24 18:21 ` Stefan Monnier @ 2015-06-24 21:10 ` tomas 2015-06-25 3:23 ` Stefan Monnier 2015-06-24 23:31 ` Emanuel Berg ` (2 subsequent siblings) 3 siblings, 1 reply; 44+ messages in thread From: tomas @ 2015-06-24 21:10 UTC (permalink / raw) To: Stefan Monnier; +Cc: help-gnu-emacs -----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----- ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-06-24 21:10 ` tomas @ 2015-06-25 3:23 ` Stefan Monnier 2015-06-25 7:47 ` tomas 0 siblings, 1 reply; 44+ messages in thread From: Stefan Monnier @ 2015-06-25 3:23 UTC (permalink / raw) To: tomas; +Cc: help-gnu-emacs > 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-06-25 3:23 ` Stefan Monnier @ 2015-06-25 7:47 ` tomas 2015-06-26 15:01 ` Emanuel Berg 0 siblings, 1 reply; 44+ messages in thread From: tomas @ 2015-06-25 7:47 UTC (permalink / raw) To: Stefan Monnier; +Cc: help-gnu-emacs -----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----- ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-06-25 7:47 ` tomas @ 2015-06-26 15:01 ` Emanuel Berg 2015-06-26 20:25 ` Marcin Borkowski 0 siblings, 1 reply; 44+ messages in thread From: Emanuel Berg @ 2015-06-26 15:01 UTC (permalink / raw) To: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-06-26 15:01 ` Emanuel Berg @ 2015-06-26 20:25 ` Marcin Borkowski 2015-06-26 22:48 ` Emanuel Berg 2015-06-27 12:11 ` Robert Thorpe 0 siblings, 2 replies; 44+ messages in thread From: Marcin Borkowski @ 2015-06-26 20:25 UTC (permalink / raw) To: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-06-26 20:25 ` Marcin Borkowski @ 2015-06-26 22:48 ` Emanuel Berg 2015-06-27 12:11 ` Robert Thorpe 1 sibling, 0 replies; 44+ messages in thread From: Emanuel Berg @ 2015-06-26 22:48 UTC (permalink / raw) To: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-06-26 20:25 ` Marcin Borkowski 2015-06-26 22:48 ` Emanuel Berg @ 2015-06-27 12:11 ` Robert Thorpe 2015-06-27 13:12 ` tomas 1 sibling, 1 reply; 44+ messages in thread From: Robert Thorpe @ 2015-06-27 12:11 UTC (permalink / raw) To: Marcin Borkowski; +Cc: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-06-27 12:11 ` Robert Thorpe @ 2015-06-27 13:12 ` tomas 2015-06-27 23:02 ` Emanuel Berg 0 siblings, 1 reply; 44+ messages in thread From: tomas @ 2015-06-27 13:12 UTC (permalink / raw) To: Robert Thorpe; +Cc: help-gnu-emacs -----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----- ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-06-27 13:12 ` tomas @ 2015-06-27 23:02 ` Emanuel Berg 2015-06-28 11:07 ` tomas 0 siblings, 1 reply; 44+ messages in thread From: Emanuel Berg @ 2015-06-27 23:02 UTC (permalink / raw) To: help-gnu-emacs <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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-06-27 23:02 ` Emanuel Berg @ 2015-06-28 11:07 ` tomas 2015-06-28 15:50 ` Emanuel Berg 0 siblings, 1 reply; 44+ messages in thread From: tomas @ 2015-06-28 11:07 UTC (permalink / raw) To: help-gnu-emacs -----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----- ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-06-28 11:07 ` tomas @ 2015-06-28 15:50 ` Emanuel Berg 2015-06-28 16:35 ` Yuri Khan 2015-06-28 21:38 ` Robert Thorpe 0 siblings, 2 replies; 44+ messages in thread From: Emanuel Berg @ 2015-06-28 15:50 UTC (permalink / raw) To: help-gnu-emacs <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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-06-28 15:50 ` Emanuel Berg @ 2015-06-28 16:35 ` Yuri Khan 2015-06-28 20:03 ` Emanuel Berg 2015-06-28 21:38 ` Robert Thorpe 1 sibling, 1 reply; 44+ messages in thread From: Yuri Khan @ 2015-06-28 16:35 UTC (permalink / raw) To: help-gnu-emacs@gnu.org 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-06-28 16:35 ` Yuri Khan @ 2015-06-28 20:03 ` Emanuel Berg 0 siblings, 0 replies; 44+ messages in thread From: Emanuel Berg @ 2015-06-28 20:03 UTC (permalink / raw) To: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-06-28 15:50 ` Emanuel Berg 2015-06-28 16:35 ` Yuri Khan @ 2015-06-28 21:38 ` Robert Thorpe 2015-06-28 23:47 ` Emanuel Berg 1 sibling, 1 reply; 44+ messages in thread From: Robert Thorpe @ 2015-06-28 21:38 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-06-28 21:38 ` Robert Thorpe @ 2015-06-28 23:47 ` Emanuel Berg 2015-07-02 23:37 ` Robert Thorpe 0 siblings, 1 reply; 44+ messages in thread From: Emanuel Berg @ 2015-06-28 23:47 UTC (permalink / raw) To: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-06-28 23:47 ` Emanuel Berg @ 2015-07-02 23:37 ` Robert Thorpe 2015-07-03 3:36 ` Yuri Khan ` (2 more replies) 0 siblings, 3 replies; 44+ messages in thread From: Robert Thorpe @ 2015-07-02 23:37 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-07-02 23:37 ` Robert Thorpe @ 2015-07-03 3:36 ` Yuri Khan 2015-07-03 6:41 ` Eli Zaretskii 2015-07-03 6:09 ` tomas [not found] ` <mailman.6215.1435903802.904.help-gnu-emacs@gnu.org> 2 siblings, 1 reply; 44+ messages in thread From: Yuri Khan @ 2015-07-03 3:36 UTC (permalink / raw) To: Robert Thorpe; +Cc: help-gnu-emacs@gnu.org, Emanuel Berg 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-07-03 3:36 ` Yuri Khan @ 2015-07-03 6:41 ` Eli Zaretskii 2015-07-03 11:48 ` Yuri Khan 0 siblings, 1 reply; 44+ messages in thread From: Eli Zaretskii @ 2015-07-03 6:41 UTC (permalink / raw) To: help-gnu-emacs > 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-07-03 6:41 ` Eli Zaretskii @ 2015-07-03 11:48 ` Yuri Khan 2015-07-03 12:16 ` Eli Zaretskii 0 siblings, 1 reply; 44+ messages in thread From: Yuri Khan @ 2015-07-03 11:48 UTC (permalink / raw) To: Eli Zaretskii; +Cc: help-gnu-emacs@gnu.org 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-07-03 11:48 ` Yuri Khan @ 2015-07-03 12:16 ` Eli Zaretskii 2015-07-03 22:59 ` Robert Thorpe 0 siblings, 1 reply; 44+ messages in thread From: Eli Zaretskii @ 2015-07-03 12:16 UTC (permalink / raw) To: help-gnu-emacs > 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.) ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-07-03 12:16 ` Eli Zaretskii @ 2015-07-03 22:59 ` Robert Thorpe 0 siblings, 0 replies; 44+ messages in thread From: Robert Thorpe @ 2015-07-03 22:59 UTC (permalink / raw) To: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-07-02 23:37 ` Robert Thorpe 2015-07-03 3:36 ` Yuri Khan @ 2015-07-03 6:09 ` tomas 2015-07-03 19:56 ` Emanuel Berg [not found] ` <mailman.6215.1435903802.904.help-gnu-emacs@gnu.org> 2 siblings, 1 reply; 44+ messages in thread From: tomas @ 2015-07-03 6:09 UTC (permalink / raw) To: Robert Thorpe; +Cc: help-gnu-emacs, Emanuel Berg -----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----- ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-07-03 6:09 ` tomas @ 2015-07-03 19:56 ` Emanuel Berg 0 siblings, 0 replies; 44+ messages in thread From: Emanuel Berg @ 2015-07-03 19:56 UTC (permalink / raw) To: help-gnu-emacs <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 ^ permalink raw reply [flat|nested] 44+ messages in thread
[parent not found: <mailman.6215.1435903802.904.help-gnu-emacs@gnu.org>]
* Re: Check for redundancy [not found] ` <mailman.6215.1435903802.904.help-gnu-emacs@gnu.org> @ 2015-07-03 6:38 ` Rusi 2015-07-03 7:54 ` tomas 2015-07-03 8:55 ` Loris Bennett 0 siblings, 2 replies; 44+ messages in thread From: Rusi @ 2015-07-03 6:38 UTC (permalink / raw) To: help-gnu-emacs 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-07-03 6:38 ` Rusi @ 2015-07-03 7:54 ` tomas 2015-07-03 8:55 ` Loris Bennett 1 sibling, 0 replies; 44+ messages in thread From: tomas @ 2015-07-03 7:54 UTC (permalink / raw) To: Rusi; +Cc: help-gnu-emacs -----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----- ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-07-03 6:38 ` Rusi 2015-07-03 7:54 ` tomas @ 2015-07-03 8:55 ` Loris Bennett 1 sibling, 0 replies; 44+ messages in thread From: Loris Bennett @ 2015-07-03 8:55 UTC (permalink / raw) To: help-gnu-emacs 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-06-24 18:21 ` Stefan Monnier 2015-06-24 21:10 ` tomas @ 2015-06-24 23:31 ` Emanuel Berg 2015-06-25 2:03 ` Óscar Fuentes [not found] ` <mailman.5603.1435188769.904.help-gnu-emacs@gnu.org> 3 siblings, 0 replies; 44+ messages in thread From: Emanuel Berg @ 2015-06-24 23:31 UTC (permalink / raw) To: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-06-24 18:21 ` Stefan Monnier 2015-06-24 21:10 ` tomas 2015-06-24 23:31 ` Emanuel Berg @ 2015-06-25 2:03 ` Óscar Fuentes 2015-06-25 2:07 ` Emanuel Berg [not found] ` <mailman.5603.1435188769.904.help-gnu-emacs@gnu.org> 3 siblings, 1 reply; 44+ messages in thread From: Óscar Fuentes @ 2015-06-25 2:03 UTC (permalink / raw) To: help-gnu-emacs 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] ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-06-25 2:03 ` Óscar Fuentes @ 2015-06-25 2:07 ` Emanuel Berg 2015-06-25 2:53 ` Óscar Fuentes 0 siblings, 1 reply; 44+ messages in thread From: Emanuel Berg @ 2015-06-25 2:07 UTC (permalink / raw) To: help-gnu-emacs Ó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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-06-25 2:07 ` Emanuel Berg @ 2015-06-25 2:53 ` Óscar Fuentes 2015-06-25 3:21 ` Emanuel Berg 0 siblings, 1 reply; 44+ messages in thread From: Óscar Fuentes @ 2015-06-25 2:53 UTC (permalink / raw) To: help-gnu-emacs 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-06-25 2:53 ` Óscar Fuentes @ 2015-06-25 3:21 ` Emanuel Berg 0 siblings, 0 replies; 44+ messages in thread From: Emanuel Berg @ 2015-06-25 3:21 UTC (permalink / raw) To: help-gnu-emacs Ó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 ^ permalink raw reply [flat|nested] 44+ messages in thread
[parent not found: <mailman.5603.1435188769.904.help-gnu-emacs@gnu.org>]
* Re: Check for redundancy [not found] ` <mailman.5603.1435188769.904.help-gnu-emacs@gnu.org> @ 2015-06-25 7:43 ` Stefan Nobis 2015-06-25 8:52 ` Andreas Röhler ` (2 more replies) 0 siblings, 3 replies; 44+ messages in thread From: Stefan Nobis @ 2015-06-25 7:43 UTC (permalink / raw) To: help-gnu-emacs 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-06-25 7:43 ` Stefan Nobis @ 2015-06-25 8:52 ` Andreas Röhler 2015-06-26 14:51 ` Emanuel Berg 2015-06-26 14:39 ` Emanuel Berg [not found] ` <mailman.5719.1435329683.904.help-gnu-emacs@gnu.org> 2 siblings, 1 reply; 44+ messages in thread From: Andreas Röhler @ 2015-06-25 8:52 UTC (permalink / raw) To: help-gnu-emacs 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-06-25 8:52 ` Andreas Röhler @ 2015-06-26 14:51 ` Emanuel Berg 0 siblings, 0 replies; 44+ messages in thread From: Emanuel Berg @ 2015-06-26 14:51 UTC (permalink / raw) To: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-06-25 7:43 ` Stefan Nobis 2015-06-25 8:52 ` Andreas Röhler @ 2015-06-26 14:39 ` Emanuel Berg [not found] ` <mailman.5719.1435329683.904.help-gnu-emacs@gnu.org> 2 siblings, 0 replies; 44+ messages in thread From: Emanuel Berg @ 2015-06-26 14:39 UTC (permalink / raw) To: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
[parent not found: <mailman.5719.1435329683.904.help-gnu-emacs@gnu.org>]
* Re: Check for redundancy [not found] ` <mailman.5719.1435329683.904.help-gnu-emacs@gnu.org> @ 2015-06-27 7:40 ` Stefan Nobis 2015-06-28 2:02 ` Emanuel Berg 0 siblings, 1 reply; 44+ messages in thread From: Stefan Nobis @ 2015-06-27 7:40 UTC (permalink / raw) To: help-gnu-emacs 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-06-27 7:40 ` Stefan Nobis @ 2015-06-28 2:02 ` Emanuel Berg 2015-06-28 2:40 ` Emanuel Berg 0 siblings, 1 reply; 44+ messages in thread From: Emanuel Berg @ 2015-06-28 2:02 UTC (permalink / raw) To: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Check for redundancy 2015-06-28 2:02 ` Emanuel Berg @ 2015-06-28 2:40 ` Emanuel Berg 0 siblings, 0 replies; 44+ messages in thread From: Emanuel Berg @ 2015-06-28 2:40 UTC (permalink / raw) To: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
end of thread, other threads:[~2015-07-03 22:59 UTC | newest] Thread overview: 44+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <mailman.6209.1435880273.904.help-gnu-emacs@gnu.org> 2015-07-03 8:40 ` Check for redundancy Pascal J. Bourguignon 2015-07-03 20:04 ` Emanuel Berg 2015-06-24 9:29 Andreas Röhler 2015-06-24 13:23 ` Drew Adams 2015-06-24 14:55 ` Andreas Röhler [not found] ` <mailman.5580.1435157733.904.help-gnu-emacs@gnu.org> 2015-06-24 18:21 ` Stefan Monnier 2015-06-24 21:10 ` tomas 2015-06-25 3:23 ` Stefan Monnier 2015-06-25 7:47 ` tomas 2015-06-26 15:01 ` Emanuel Berg 2015-06-26 20:25 ` Marcin Borkowski 2015-06-26 22:48 ` Emanuel Berg 2015-06-27 12:11 ` Robert Thorpe 2015-06-27 13:12 ` tomas 2015-06-27 23:02 ` Emanuel Berg 2015-06-28 11:07 ` tomas 2015-06-28 15:50 ` Emanuel Berg 2015-06-28 16:35 ` Yuri Khan 2015-06-28 20:03 ` Emanuel Berg 2015-06-28 21:38 ` Robert Thorpe 2015-06-28 23:47 ` Emanuel Berg 2015-07-02 23:37 ` Robert Thorpe 2015-07-03 3:36 ` Yuri Khan 2015-07-03 6:41 ` Eli Zaretskii 2015-07-03 11:48 ` Yuri Khan 2015-07-03 12:16 ` Eli Zaretskii 2015-07-03 22:59 ` Robert Thorpe 2015-07-03 6:09 ` tomas 2015-07-03 19:56 ` Emanuel Berg [not found] ` <mailman.6215.1435903802.904.help-gnu-emacs@gnu.org> 2015-07-03 6:38 ` Rusi 2015-07-03 7:54 ` tomas 2015-07-03 8:55 ` Loris Bennett 2015-06-24 23:31 ` Emanuel Berg 2015-06-25 2:03 ` Óscar Fuentes 2015-06-25 2:07 ` Emanuel Berg 2015-06-25 2:53 ` Óscar Fuentes 2015-06-25 3:21 ` Emanuel Berg [not found] ` <mailman.5603.1435188769.904.help-gnu-emacs@gnu.org> 2015-06-25 7:43 ` Stefan Nobis 2015-06-25 8:52 ` Andreas Röhler 2015-06-26 14:51 ` Emanuel Berg 2015-06-26 14:39 ` Emanuel Berg [not found] ` <mailman.5719.1435329683.904.help-gnu-emacs@gnu.org> 2015-06-27 7:40 ` Stefan Nobis 2015-06-28 2:02 ` Emanuel Berg 2015-06-28 2:40 ` Emanuel Berg
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.