Re: mode in functions
On 01-Jun-2000, Ketil Malde [EMAIL PROTECTED] wrote: Jan Skibinski [EMAIL PROTECTED] writes: For tar_x, tar_xv, tar_v kind of things people invented objects, recognizing that "tar -x" approach is not a user friendly technology. Oh? You realize there are Unix weenies on this list, don't you? Cryptic commands with equally cryptic options is very user friendly for an interactive command line. The emphasis there should be on _interactive_. An interactive command line tool and a programming language intended for writing non-trivial applications have very different requirements. For the former, brevity may well be more important than readability, but for the latter it is definitely the other way around. -- Fergus Henderson [EMAIL PROTECTED] | "I have always known that the pursuit WWW: http://www.cs.mu.oz.au/~fjh | of excellence is a lethal habit" PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.
Re: mode in functions
On 02-Jun-2000, S.D.Mechveliani [EMAIL PROTECTED] wrote: Ketil Malde [EMAIL PROTECTED] writes I could accept "mode flags" if the algorithm is extremely similar, e.g. passing a comparator function to a sort is a kind of mode flag (think ordered/reversed) which I think is perfectly acceptable. Having flags indicating algorithm to use (sort Merge (s:ss)) is IMHO silly. Not at all. Silly it to call differently the functions that compute the same map. Also silly is to have quotRem divMod instead of quotRem mode. In addition to the criticisms that have already been leveled against this approach, another drawback with it is that makes things less extensible. For example, with the current approach, if I want to define a new sorting function, I just go ahead and do so, and apart from the user of my new function having to import my module, my new sorting function is completely first class, just like any sorting functions that are provided by the Prelude or standard libraries. But if we use mode arguments with some enumeration type, then there's no easy way for me to add a new enumeration constant to the enum, or to change the standard `sort' function so that it can call my sort function. So my new sort function ends up being in some sense a second-class citizen in comparison to the various different sort functions encapsulated as different modes of the standard `sort' function. For example, someone writing an algorithm that makes use of a sorting function might well make the mistake of abstracting away which kind of sort function is used by passing in a SortMode argument, foo :: SortMode - ... foo mode ... = (sort mode) ... rather than by passing in a sort function. If they did that, then I wouldn't be able to make `foo' use my own sort function. (Note that using `Char' rather than an enumeration doesn't help with this problem.) -- Fergus Henderson [EMAIL PROTECTED] | "I have always known that the pursuit WWW: http://www.cs.mu.oz.au/~fjh | of excellence is a lethal habit" PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.
Re: mode in functions
Jan Skibinski [EMAIL PROTECTED] writes: I watch in amusement how my name is glued to someone else's prose. I mildly protest :-) Hah! You question a certain OS, you should expect your comments to get snipped! Servers you right, it does. :-) -kzm -- If I haven't seen further, it is by standing in the footprints of giants
Re: mode in functions
On 02-Jun-2000, Ketil Malde [EMAIL PROTECTED] wrote: Fergus Henderson [EMAIL PROTECTED] writes: An interactive command line tool and a programming language intended for writing non-trivial applications have very different requirements. For the former, brevity may well be more important than readability, but for the latter it is definitely the other way around. But verbosity is not the same as readability! "head" is a perfectly good name for a function that returns the first element of a list, even though firstElementOf might be more descriptive. ... So, commonly used names should be short I agree. But single character names, as originally suggested in this thread, are too short; at that point, readability has definitely been compromised. Only the most pervasive operations would warrant names so short, and modes for operations like sorting certainly don't fall into that category. -- Fergus Henderson [EMAIL PROTECTED] | "I have always known that the pursuit WWW: http://www.cs.mu.oz.au/~fjh | of excellence is a lethal habit" PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.
mode in functions
Fergus Henderson [EMAIL PROTECTED] writes on 1 Jun 2000 'n' :: Char does not hold a name in the constructor name space. Yes, but it is also far from self-expanatory. With a constructor name, in a suitable environment you could just click on the constructor name and the environment would immediately pop up the declaration and documentation for that constructor and the type that it belongs to. [..] [..] data Mode_sort = Sort_quick | Sort_merge | Sort_insert | Sort_other deriving(Eq,Ord,Enum,Show,Read) ... Again, `Positive' would not do, it should be something like QuotRem_Positive, and so on. This is a problem with Haskell, IMHO. Mercury allows overloading of constructor names, so in Mercury you could use just `Positive' rather than `QuotRem_Positive'. The type checker will resolve the ambiguity whenever possible. This is my wish for Haskell-2: overloded constructor names. In many cases, these name overlaps can be resolved. f x y b = myRem 'c' ((myRem '_' x b)*(myRem '_' y b)) b Now, it has to be, maybe, remP = rem QuotRem_positive remO = rem QuotRem_other f x y = remP ((remO x b)*(remO x b)) b Maybe, Char is better? No, IMHO Char would definitely not be better. In this case, I think separate functions would be best, a single function with a properly typed mode argument second best, and a single function with a `Char' mode argument worst. About the type constructor for mode, I half-agree. But about a single function - no. If you require the single functions sort_merge, sort_insert, sort_quick, do you also require tar_x, tar_xv, tar_v instead of tar mode ? As to quotRem - diveRem, it has the three extra friends to export. -- Sergey Mechveliani [EMAIL PROTECTED]
Re: mode in functions
On Thu, 1 Jun 2000, S.D.Mechveliani wrote: About the type constructor for mode, I half-agree. But about a single function - no. If you require the single functions sort_merge, sort_insert, sort_quick, do you also require tar_x, tar_xv, tar_v instead of tar mode ? As to quotRem - diveRem, it has the three extra friends to export. Since we are expressing "i_like --i_dislike" opinions, here is mine: For tar_x, tar_xv, tar_v kind of things people invented objects, recognizing that "tar -x" approach is not a user friendly technology. Jan
mode for functions
D. Tweed [EMAIL PROTECTED] writes on 1 Jun 2000 We also may paste True :: Bool instead of False (the type design does not help), x / 0 instead of x / 2, take n xs instead of take (-n) xs We also may forget to write a program and try to use it. Do you really believe the general principle that `if something is inherently error prone then something is only worth doing if it solves all the errors completely, not if it only makes things slightly less error prone?' That would suggest that strong typing, haskell style modules and numerous other innovations are mistakes made in the language design process. I meant: if 3/4 of errors still remain after the perfect type design, maybe, the place of this type design is not so important. data ModeQuotRem = QuotRem_minRem | QuotRem_positive | QuotRem_other deriving(Eq,Ord,Enum,Show,Read) -- contrived data Mode_sort = Sort_quick | Sort_merge | Sort_insert | Sort_other deriving(Eq,Ord,Enum,Show,Read) ... Again, `Positive' would not do, it should be something like QuotRem_Positive, and so on. The only collision here if you remove the QuotRem_ Sort_ prefixes comes from the other, which seems like excess generality to me: do you really want an option to use a QuotRem function in a mode about which you know nothing. By _other I meant _Default. For example, Sort_other means "sort as you (library) can". If Fergus' suggestion about allowing overloaded data constructors for H-2 is allowed then I've no problem with multiple instances of Positive With the overloaded data constructors, the special data types for the Mode may have sense. [..] The problem with chars is if for example `p' means positive (ie =0) in one function and strictly-positive (ie 0) in another [..] The manual on a Mode is the part of the manual on a function. See a function, and it shows what the mode values mean. Like everywhere in the world. The mode value names themself are somewhat senseless, they have sense only inside the manual on the function. -- Sergey Mechveliani [EMAIL PROTECTED]
Re: mode for functions
"S.D.Mechveliani" wrote: D. Tweed [EMAIL PROTECTED] writes on 1 Jun 2000 We also may paste True :: Bool instead of False (the type design does not help), x / 0 instead of x / 2, take n xs instead of take (-n) xs We also may forget to write a program and try to use it. Do you really believe the general principle that `if something is inherently error prone then something is only worth doing if it solves all the errors completely, not if it only makes things slightly less error prone?' That would suggest that strong typing, haskell style modules and numerous other innovations are mistakes made in the language design process. I meant: if 3/4 of errors still remain after the perfect type design, maybe, the place of this type design is not so important. I totally disagree. I would say that at most 1/4 of the errors remain when you've fixed the type errors. Perhaps you're not taking full advantage of the type system? Using Char for a mode would certainly be a case of not using the type system to your advantage. Never reuse types! Make new types for everything! :) -- -- Lennart
Re: mode in functions
Jan Skibinski [EMAIL PROTECTED] writes: On Thu, 1 Jun 2000, S.D.Mechveliani wrote: If you require the single functions sort_merge, sort_insert, sort_quick, do you also require tar_x, tar_xv, tar_v instead of tar mode ? If tar was implemented in Haskell, it'd be a module with functions like "extract" (tar_x) "extractVerbose" (tar_xv) and "uselessFunction" (tar_v). IMHO. So, I think the comparision is flawed. I could accept "mode flags" if the algorithm is extremely similar, e.g. passing a comparator function to a sort is a kind of mode flag (think ordered/reversed) which I think is perfectly acceptable. Having flags indicating algorithm to use (sort Merge (s:ss)) is IMHO silly. For tar_x, tar_xv, tar_v kind of things people invented objects, recognizing that "tar -x" approach is not a user friendly technology. Oh? You realize there are Unix weenies on this list, don't you? Cryptic commands with equally cryptic options is very user friendly for an interactive command line. I'm a lot more flexible, effective and efficient with that, than with any "object"-branded user interface I've tried. -kzm -- If I haven't seen further, it is by standing in the footprints of giants
Re: mode in functions
On 1 Jun 2000, Ketil Malde wrote: I could accept "mode flags" if the algorithm is extremely similar, e.g. passing a comparator function to a sort is a kind of mode flag (think ordered/reversed) which I think is perfectly acceptable. Having flags indicating algorithm to use (sort Merge (s:ss)) is IMHO silly. There are cases where functions taking mode arguments might be more easily usable than duplicate functions (note I'm not necessarily arguing this is one of them) because various things can be done on the mode value (eg, equality tests, automatic enumeration, etc) which can't be done on the functions themselves. The following bizarre code (which runs in Hugs Jan 98 at least) indicates the sort of thing import Maybe data FType = F | G | H deriving (Eq,Ord,Enum,Show) operation::FType - a - Maybe a operation H a = Just a operation _ _ = Nothing tryUntilSucceedWithOperation::Eq a=a-a tryUntilSucceedWithOperation x =(fromJust.head.dropWhile (==Nothing). (map (flip operation x))) (enumFrom F) where operation is the library code and tryUntil... is the end-user code. (Obviously operation would be something with a less predictable succeed/fail pattern.) Then adding a new method with FType J, say, just requires slotting J into the appropriate position in FType and everything else works automatically. I can half see how you might be able use typed mode arguments to do some things in a much simpler way than with complete different functions, but I haven't the time to resolve it to a convincing real world example, so I may be wrong :-) ___cheers,_dave www.cs.bris.ac.uk/~tweed/pi.htm|I shoulda realised building the email: [EMAIL PROTECTED] |memory allocation subsytem with work tel: (0117) 954-5253 |--with-malicious-ai was a bad idea.
Re: mode in functions
On 1 Jun 2000, Ketil Malde wrote: Jan Skibinski [EMAIL PROTECTED] writes: For tar_x, tar_xv, tar_v kind of things people invented objects, recognizing that "tar -x" approach is not a user friendly technology. Oh? You realize there are Unix weenies on this list, don't you? Cryptic commands with equally cryptic options is very user friendly for an interactive command line. I'm a lot more flexible, effective and efficient with that, than with any "object"-branded user interface I've tried. Well, I said that it was just mine opinion, to which I stick. "De gustibus non est disputandum". No need to feel offended about Unix. I use Linux every day. But that does not change my opinion about switches. This is the olden days technology. I do not know what "object-branded" interfaces you are familiar with, but NextStep for example was able to hide all those unpleasent things quite nicely and tar was (is?) quite friendly there. [And you also had all fancy filters automatically appearing in any application menu. Nice interprocess communication. But you could still use scripts as in any other Unix, of course.] Tar command is really a very good example. I was quite tempted to copy here a header of "man tar", but I guess everyone knows how big this beast is. I certainly would not wish to cope with anything like this in any language I use -- unless I re-wrote it first to some friendlier form. Jan
Re: mode in functions
On Thu, Jun 01, 2000 at 07:23:55PM +0200, Ketil Malde wrote: Jan Skibinski [EMAIL PROTECTED] writes: On Thu, 1 Jun 2000, S.D.Mechveliani wrote: If you require the single functions sort_merge, sort_insert, sort_quick, do you also require tar_x, tar_xv, tar_v instead of tar mode ? If tar was implemented in Haskell, it'd be a module with functions like "extract" (tar_x) "extractVerbose" (tar_xv) and "uselessFunction" (tar_v). IMHO. So, I think the comparision is flawed. I could accept "mode flags" if the algorithm is extremely similar, e.g. passing a comparator function to a sort is a kind of mode flag (think ordered/reversed) which I think is perfectly acceptable. Having flags indicating algorithm to use (sort Merge (s:ss)) is IMHO silly. It seems to me that mode flags only really make sense when we're combining modes. To continue the tar example it might be a bit much to have extractVerbosePreserve, extractPreserve etc etc. This is also done in C by |'ing 'flags' together for things like open(). So mode flags make sense in UNIX and C. In Haskell we combine functions and use higher order functions, à la sortBy. For tar probably the best would be generating a list of the files in the archive, including information like modification time and permissions and then mapping onto that the composition of funtions that have type FileInfo - IO FileInfo. So if you wanted to extract and preserve you'd do 'mapTar (extract . preserve)', adding in verbose and so on if you wanted. -- -Simon Raahauge DeSantis
Re: mode in functions
I watch in amusement how my name is glued to someone else's prose. I mildly protest :-) Jan
Re: mode in functions
Simon Raahauge DeSantis [EMAIL PROTECTED] writes: It seems to me that mode flags only really make sense when we're combining modes. To continue the tar example it might be a bit much to have extractVerbosePreserve, extractPreserve etc etc. This is also done in C by |'ing 'flags' together for things like open(). So mode flags make sense in UNIX and C. In Haskell we combine functions and use higher order functions, à la sortBy. For tar probably the best would be generating a list of the files in the archive, including information like modification time and permissions and then mapping onto that the composition of funtions that have type FileInfo - IO FileInfo. So if you wanted to extract and preserve you'd do 'mapTar (extract . preserve)', adding in verbose and so on if you wanted. Another option which preserves strong typing would be lists of strongly-typed mode settings. HOpenGL uses things like this in places where the original OpenGL used bitflags. Something like: tarExtract [Tar.PreservePermissions, Tar.Verbose] "foo.tar" Carl Witty [EMAIL PROTECTED]
Re: mode in functions
On Thu, Jun 01, 2000 at 04:06:59PM -0400, Jan Skibinski wrote: I watch in amusement how my name is glued to someone else's prose. I mildly protest :-) Jan Sorry about that. If you pay close attention to the quoting levels (as I obviously did not) there's no actual text attributed to you but it is unclear. My apologies for firing off so quickly. (But this character as mode argument really seems like a terrible idea) -- -Simon Raahauge DeSantis
mode in functions
Ketil Malde [EMAIL PROTECTED] writes I could accept "mode flags" if the algorithm is extremely similar, e.g. passing a comparator function to a sort is a kind of mode flag (think ordered/reversed) which I think is perfectly acceptable. Having flags indicating algorithm to use (sort Merge (s:ss)) is IMHO silly. Not at all. Silly it to call differently the functions that compute the same map. Also silly is to have quotRem divMod instead of quotRem mode. --- Observation on the literature. There appeared a nice manner for the public discussion introduced recently by M.Kowalsky and encouraged by L.Augustsson: using elengantly the words "silly", "ugly", "crazy", "blathering", and so on. The Haskell place is in bloom, enjoying concentration of culture. -- Sergey Mechveliani [EMAIL PROTECTED]
