"Johan Tibell" <[EMAIL PROTECTED]> writes:
>>> The benefit would be that if the input is not in latin-1 an exception
>>> could be thrown rather than returning a Char representing the wrong
>>> Unicode code point.
>> I'm not sure what you mean here. All 256 possible values have a meaning.
OTOH, g
Henning Thielemann <[EMAIL PROTECTED]> writes:
>> #if HUGS
>> import Hugs.Base
>> #elseif GHC
>> import GHC.Base
>> #endif
> We just need a system for plugging together system-dependent modules,
> that's all. We do not need preprocessor hacks for this issue:
> http://www.haskell.org/pipermail/
Henning Thielemann <[EMAIL PROTECTED]> writes:
>> 1. allow to use '_' in number literals. its used in Ruby and i found
>> that this makes long number literals much more readable. for example
> Sounds like something that can be solved with an infix operator:
> (~~) :: Integer -> Integer -> Intege
"Iavor Diatchki" <[EMAIL PROTECTED]> writes:
> A question about the syntax: would there be a problem if we made the
> 'deriving' declaration look like an instance?
And you might as well keep the 'instance' keyword when instantiating,
even if the instance is derived? Seems more consistent to me
[EMAIL PROTECTED] writes:
> In my personal experience, I have three kinds of Haskell modules:
>
> 1. Exporting everything
> 2. Exporting almost everything
> 3. Having a designed export interface
I tend to start out exporting everything, which I find useful for
testing the internals, and so
Benjamin Franksen <[EMAIL PROTECTED]> writes:
>> If this means that you must import Data.List almost everywhere, this
>> won't change anything - only add yet another import to every file.
> But you could import something different instead!
Yes. You can do that as it is, of course (well, more or
Malcolm Wallace <[EMAIL PROTECTED]> writes:
> One of the problems with the current mechanism for overriding Prelude
> definitions, is that every module that /uses/ such an entity must
> also explicitly hide the original Prelude:
I guess I don't quite understand what you are trying to achieve.
Ca
Malcolm Wallace <[EMAIL PROTECTED]> writes:
> you would simply replace the implicit "import Prelude" with
> an explicit "import Prelude.Standard" (or use a build flag like
> -fimplicit-prelude, or +98).
Why not keep it implicit? If you want the alternative behavior, you
know where to get it (imp
Wolfgang Jeltsch <[EMAIL PROTECTED]> writes:
>> Personally, I would greatly prefer to have libraries that do not clash
>> with common Prelude functions.
> I would solve this problem by reducing the Prelude to just a core. List
> function could go, for example, (mostly) into Data.List.
If this
Ketil Malde <[EMAIL PROTECTED]> writes:
> Personally, I would greatly prefer to have libraries that do not clash
> with common Prelude functions.
Slightly related in spirit:
Often additions to the language tends to change the meaning of
existing programs: Implicit parameters br
Wolfgang Jeltsch <[EMAIL PROTECTED]> writes:
> On the other hand, sometimes it makes sense to have a "mostly qualified"
> import. For example, if you import Data.Set or Data.Map you might want only
> the type constructors to be imported unqualified and the rest to be imported
> qualified.
Per
11 matches
Mail list logo
