text: On 27/02/2004, at 4:48 PM, Brandon Michael Moore wrote: > On Fri, 27 Feb 2004 ozone at algorithm.com.au wrote: > >> On 27/02/2004, at 1:13 PM, oleg at pobox.com wrote: >> >> 1) now I have to manually declare a class definition for every single >> function, and I have to declare it in advance before any module >> defines >> that function (most serious problem; see below), >> >> 2) I then have to declare instances of that type class for every >> function I define, >> >> 3) the type signature for phase reveals no clues about how to use that >> function. > > Declaring a type class instance is really no problem. I agree that declaring a type class instance per function is not a huge deal (if it can be automatically done by the compiler). However, declaring the instance first requires declaring the type class itself, and that _is_ a problem, because that's exactly what I'm trying to work around. Without 20/20 hindsight, you cannot say with certainty what type signatures a "generic" function (like 'phase' or even 'add') can support, because it's not a generic function,. >> With the per-type namespace separation I'm advocating, you do not need >> to know and declare in advance that each function "will be" >> overloaded, >> you simply write a FiniteMap.add function and a Set.add function, and >> you get a simpler form of namespace separation (or overloading) based >> on the first parameter that's passed to it. It is a solution which is >> more _flexible_ than requiring type class definitions, and it is >> better >> than having hungarian notation for functions. In fact, I think that, >> right now, if we replaced the current namespace separation offered by >> the hierarchical module system, and instead only had this sort of >> per-type namespace separation, things would still be better! > >. >> I realise my idea isn't very general in that it only allows this >> namespace lookup/overloading based on the type of a single argument >> parameter, and I think it would be possible with a bit more thinking >> to >> generalise it to work based on multiple arguments (e.g. via >> argument-dependent lookup, or whatnot). But even in its current form, >> I honestly think it offers far more flexibility and would lead to >> cleaner APIs than is currently possible. > >