tag:blogger.com,1999:blog-8972783911534754044.post5096205875223134719..comments2023-08-21T10:24:10.591+02:00Comments on Liberty Eiffel: Case sensitivityAnonymoushttp://www.blogger.com/profile/03026537587693318231noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-8972783911534754044.post-83823863508675434512012-02-29T17:15:14.680+01:002012-02-29T17:15:14.680+01:00I don't know any fitting programming language ...I don't know any fitting programming language - I'm a dusty'n'dirty civil engineer after all - yet all our mumbling about case sensitivity of Eiffel somehow remind me of my AmigaOs filesystem which is case-insensitive with case-preservation, almost the same rules of original Eiffel. <br />Case-insensitive with case-preservation (with warnings as you proposed) would robs us the possibility to write E for energy and e for the base of natural logarithms barring us to write E := K*e^(x-y)<br />We may conceive an hypotetical math-saving rule allowing the usage of these simbols matching the [:upper:](_[:alnum:])* regex (E_foo or E_my1 or G_m but not GM_asdAnonymoushttps://www.blogger.com/profile/03026537587693318231noreply@blogger.comtag:blogger.com,1999:blog-8972783911534754044.post-20501116574364825912012-02-28T14:15:51.352+01:002012-02-28T14:15:51.352+01:00I agree that lacking the possibility to express sy...I agree that lacking the possibility to express symbols in their original and common form can be pain.<br /><br />However I think the risk to have myAttribname, and myAttribName and that user use one instead of the other (developer of this class, or users of this class) is greater.<br /><br />Not sure the gain to have all symbols available in the lang compensate the high risk of bugs (as long as human do the coding...)<br /><br />So far, unicode is supported for operator (in ECMA Eiffel), which is much better than before for math expression.<br /><br />Now I guess, we can argue for ever, I can already see sometime some mistakes due to using foo_bar in place of foobar, so I can not even imagine if the language distinguish FooBar from foobar, from fooBar, from FOobaA, from fOobAr or foObAr<br />I can understand "a" need for that, I hope that no one will actually use all those variants of foobar in the same scope.<br /><br />What would be more critical for me is that reserved word for keyword, not being able to name an attribute "class" or "feature" is annoying, but still I can live with that. So I guess scientific can also accept to write Epsilon instead of ε (I could be wrong about that)<br /><br />It would be interesting to know about any programming language that allow such advanced use of Unicode in a written language.<br /><br />Any reference to such programming language ?Jocelynnoreply@blogger.comtag:blogger.com,1999:blog-8972783911534754044.post-16417337087514616912012-02-22T11:52:57.144+01:002012-02-22T11:52:57.144+01:00I fully concur with your comment but felt that suc...I fully concur with your comment but felt that such a request at this stage might be less than helpful.Frank Salternoreply@blogger.comtag:blogger.com,1999:blog-8972783911534754044.post-67344736240874606542012-02-22T10:31:02.920+01:002012-02-22T10:31:02.920+01:00Every scientific field uses a lot of symbols: civi...Every scientific field uses a lot of symbols: civil engineering, for example in the Eurocodes uses a lot of symbols like this. <br />So we must go beyond case-sensitivity and ASCII, a standard which is almost half-century old.<br />I think we shall - at least - write source code in Unicode and lay down some style guide for its usage. More on this soon...Anonymoushttps://www.blogger.com/profile/03026537587693318231noreply@blogger.comtag:blogger.com,1999:blog-8972783911534754044.post-41087605059611653602012-02-22T10:20:08.563+01:002012-02-22T10:20:08.563+01:00Yes, I do agree on your analysis: Liberty Eiffel i...Yes, I do agree on your analysis: Liberty Eiffel is a language that requires the code to follow style for feature and class names.<br />I've been pondering about it for a while and I've come to the conclusion that the style guide is a good one but we actually require the language to be case-sensitive. See the comment of Frank he is entirely right.Anonymoushttps://www.blogger.com/profile/03026537587693318231noreply@blogger.comtag:blogger.com,1999:blog-8972783911534754044.post-41927790496699845902012-02-22T09:23:17.591+01:002012-02-22T09:23:17.591+01:00I would like to suggest that user defined variable...I would like to suggest that user defined variables should be enforced as being case sensitive. Otherwise you will exclude a very large number of possible users. These are scientific and engineering programmers.<br /><br />If you look at http://cheminfo.chemi.muni.cz/ianua/epr/tab/Scientific%20Abbreviations%20and%20Symbols.pdf, you will see the reason immediately.<br /><br />In much of this work, roman, greek and other alphabetic characters are used (are required) to make manipulation of expressions managable.<br /><br />I believe that Eiffel provides a very powerful tool for physical and other simulations.<br /><br />Requiring programs to be case sensitive will include these users.Frank Salternoreply@blogger.comtag:blogger.com,1999:blog-8972783911534754044.post-11504162093409819722012-01-25T09:35:30.356+01:002012-01-25T09:35:30.356+01:00Actually, I would like that the compiler enforces ...Actually, I would like that the compiler enforces the user to use correct case, or raise warning.<br />But in practice, I am not sure this is really doable.<br /><br />The problem with constant is one, should I do a renaming with Liberty Eiffel such as ?<br /><br /> class FOO<br /> feature<br /> bar: INTEGER is<br /> do<br /> Result := 123<br /> end<br /> end<br /><br /> class FOOBAR<br /> inherit <br /> FOO <br /> rename <br /> bar as Bar <br /> redefine <br /> bar <br /> end<br /> feature<br /> Bar: INTEGER is 123<br /> end<br /><br />And then the caller .. should I use<br /> foo: FOO<br /> foobar: FOOBAR<br /> ... <br /> i := foo.bar<br /> i := foobar.Bar<br /><br /> So this mean, I have to know FOOBAR implement `Bar' as a constant ?<br /><br />In fact, I guess this particular case comes from a "not so good" style related to constant or once ... I guess we should not recommend to use first letter as uppercase, especially if the constant feature is a one letter name ...<br />This is just a nightmare when you want to do refactorying, and really .. the caller should not care if a feature is implemented as a constant or a function...<br /><br />Now, if the compiler enforces or report warning if a class has lowercase character, or similar if feature has uppercase character .. that's ok for me, this is acceptable.<br /><br />Even if sometime when wrapping a C library, it might be convenient to have for instance c_FOOBAR to wrap the value of FOOBAR macro. For me, this can help, but once again I don't have a strong position on that.<br /><br />So if a case-sensitive language .. means the compiler checks that the follows strong style/rule that's ok ...<br /><br />BUT if this means the compiler understands<br /> foobar: FOOBAR<br /> fooBar: FOOBAR<br /><br />As 2 differents entities ...<br /><br />or even class FooBar and class FOOBAR as 2 differents classes, then I think this is really bad.<br /><br />So for me Liberty Eiffel is not a case-sensitive language, it is a language that requires the code to follow style for feature and class names.<br /><br />Do you agree with my analyze?Jocelynnoreply@blogger.comtag:blogger.com,1999:blog-8972783911534754044.post-27319488212666746682012-01-25T00:22:09.593+01:002012-01-25T00:22:09.593+01:00Constants really means "something that is ori...Constants really means "something that is originally defined as constant".<br />The original definition is for something "that may/will be computed" so my guess is that this case is like:<br /><br />class FOO feature bar: INTEGER is do .... end<br /><br />class BAR inherit FOO feature bar: INTEGER is 12 end<br /><br />You may write somewhere:<br />local f: FOO; b: BAR<br />do<br /> create b<br /> f := b<br /> print (f.f.out) -- will print 12<br />end<br /><br />In that case you may not know it is sometimes constant.<br />*BUT* we may also conceive the counterexample of :<br /><br />class FOO<br /><br />feature {ANY}<br /> g: INTEGER is 42 <br /> f: INTEGER is<br /> do<br /> end<br /><br />end -- class FOO<br /><br />class BAR<br /><br />inherit<br /> FOO<br /> redefine f, g<br /> end<br /><br />feature {ANY}<br /> f: INTEGER is 12<br /> g: INTEGER is<br /> do<br /> end<br /><br />end <br /><br />So things are getting murky..... I don't have a defined opinion now... 8-/Anonymoushttps://www.blogger.com/profile/03026537587693318231noreply@blogger.comtag:blogger.com,1999:blog-8972783911534754044.post-53757002683440861052012-01-24T23:04:40.855+01:002012-01-24T23:04:40.855+01:00I forgot to sign my previous "anonymous"...I forgot to sign my previous "anonymous" comment<br />-- JocelynJocelynnoreply@blogger.comtag:blogger.com,1999:blog-8972783911534754044.post-54791460680747434722012-01-24T22:58:52.519+01:002012-01-24T22:58:52.519+01:00A quick question ...
if I have a function redefine...A quick question ...<br />if I have a function redefined into a constant ...<br /><br />how should I write the code for the caller .. with a first uppercase character or a lowercase?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8972783911534754044.post-84444935531198840272012-01-24T19:41:08.289+01:002012-01-24T19:41:08.289+01:00I absolve you if at least you use se pretty ;-)I absolve you if at least you use se pretty ;-)Cyril Adrianhttps://www.blogger.com/profile/05915629514665711947noreply@blogger.comtag:blogger.com,1999:blog-8972783911534754044.post-34022262235850096762012-01-24T16:49:43.597+01:002012-01-24T16:49:43.597+01:00Oh Cyril, I am a sinner! I left thy Holy Church of...Oh Cyril, I am a sinner! I left thy Holy Church of Emacs to embrace the vile cult of Vim!<br />Now I cannot format my code in a holy way but I have to use ancient incantations that twist the code and make it looks heretic....<br /><br />Leaving funny jokes about Emacs being a religion, I shall debug the vim Eiffel formatter as it constantly format my code wrong...Anonymoushttps://www.blogger.com/profile/03026537587693318231noreply@blogger.comtag:blogger.com,1999:blog-8972783911534754044.post-16103708365188081972011-12-23T12:19:57.799+01:002011-12-23T12:19:57.799+01:00I think it's less a matter of personal choice ...I think it's less a matter of personal choice than of consistent rules. It's a lot easier to read code if it's always formatted the same way.<br /><br />In that matter, SmartEiffel rules are quite precise. I should write a post about it.Cyril Adrianhttps://www.blogger.com/profile/05915629514665711947noreply@blogger.comtag:blogger.com,1999:blog-8972783911534754044.post-71215490492015097342011-12-22T15:04:41.729+01:002011-12-22T15:04:41.729+01:00My personal rule is to make the formal generic rea...My personal rule is to make the formal generic read like a generic name in English; so instead of LINKED_LIST[E_] I tend to write LINKED_LIST[AN_ITEM] .<br />I know my preference is not "canonical" but it make the rest of the class easier to read, at least IMHO.Anonymoushttps://www.blogger.com/profile/03026537587693318231noreply@blogger.comtag:blogger.com,1999:blog-8972783911534754044.post-18399915359032232192011-12-22T12:28:55.003+01:002011-12-22T12:28:55.003+01:00there is another rule, but that one is not enforce...there is another rule, but that one is not enforced (but used throughout the library): formal generics are terminated by an underscoreCyril Adrianhttps://www.blogger.com/profile/05915629514665711947noreply@blogger.comtag:blogger.com,1999:blog-8972783911534754044.post-77741045792297922482011-12-21T20:29:57.138+01:002011-12-21T20:29:57.138+01:00OK, so I am about to make a subjective remark. Gnu...OK, so I am about to make a subjective remark. Gnu Eiffel is doing the right thing with case.<br /><br />This version is "Eiffel-esque" in my take on the spirit of the Eiffel language, which is to say, strict in a good way, because the rules are right to the maximum degree on all scales, NOT just the big picture with sloppy mismatched details.<br /><br />Architecture is important! Not just "strategic" matters.carl37https://www.blogger.com/profile/16468983136981309662noreply@blogger.com