Haskell philosophy question

Hello, I am confused between Haskell as delineated in the Haskell Report VS ghc "pragmas" which extend Haskell beyond the Haskell Report. I am sure I am not the first to ask. Caveat: on my part, I am not against innovation/extensions, but I don't like to see language "bloat". This is not a negative/pegorative statement .... just a challenging one. Kind regards, vasili

On May 17, 2009, at 02:32 , Vasili I. Galchin wrote:
I am confused between Haskell as delineated in the Haskell Report VS ghc "pragmas" which extend Haskell beyond the Haskell Report. I am sure I am not the first to ask. Caveat: on my part, I am not against innovation/extensions, but I don't like to see language "bloat". This is not a negative/pegorative statement .... just a challenging one.
Remember that Haskell is *also* a research language; this means it regularly gets new features intended to allow research into various type system extensions. Some of these "stick" (the original type classes, and later multiple parameter type classes), some flop (linear implicit parameters), some hang around for a while before being replaced by something (hopefully) better (functional dependencies vs. type families). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

vigalchin:
Hello,
I am confused between Haskell as delineated in the Haskell Report VS ghc "pragmas" which extend Haskell beyond the Haskell Report. I am sure I am not the first to ask. Caveat: on my part, I am not against innovation/extensions, but I don't like to see language "bloat". This is not a negative/pegorative statement .... just a challenging one.
They add new features, which are useful for determining what features are useful :) -- Don

"Vasili I. Galchin"
Hello,
I am confused between Haskell as delineated in the Haskell Report VS ghc "pragmas" which extend Haskell beyond the Haskell Report.
Pragmas are part of the report, and while I agree that using them for extensions is stretching the meaning a bit, it's clearly the best way of doing it -- they're not supposed to change the semantics of the language as defined, but it doesn't say anything about what they do to stuff that isn't part of the language.
I am sure I am not the first to ask. Caveat: on my part, I am not against innovation/extensions, but I don't like to see language "bloat".
Me neither, but many of the extensions are for things that hadn't been invented (or perhaps finalised, such as heirarchical modules, IIRC) when the standard was written, and which make the language more expressive, which is a worthwhile aim. Among the stated aims of Haskell was to be a platform for language development. Pragmas keep the experimental stuff separate from the stuff one can rely on because it's part of H98. -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk

Vasili I. Galchin schrieb:
Hello,
I am confused between Haskell as delineated in the Haskell Report VS ghc "pragmas" which extend Haskell beyond the Haskell Report. I am sure I am not the first to ask. Caveat: on my part, I am not against innovation/extensions, but I don't like to see language "bloat". This is not a negative/pegorative statement .... just a challenging one.
http://www.haskell.org/haskellwiki/Use_of_language_extensions

2009/5/17 Vasili I. Galchin
Hello,
I am confused between Haskell as delineated in the Haskell Report VS ghc "pragmas" which extend Haskell beyond the Haskell Report. I am sure I am not the first to ask. Caveat: on my part, I am not against innovation/extensions, but I don't like to see language "bloat". This is not a negative/pegorative statement .... just a challenging one.
Let's say that pragmas strong type your code. With the Haskell Report, you can parse a string into a certain block of code which does some kind of functionality. With these, you will get a different type that does prett ymuch the same thing. But these advanced types can also handle certain other tricks too. The philosophy is to use the pragmas then, as declarations so you know which parser to use, etc... It also lets people pass around blocks of data and know what to do with it, rather than relying on simple version numbers. Languages do pick up features all the time. If you're looking for a different perspective, it lets us strictly sort the extensions rather than relying on vague notions such as version number, 'from __future__ import *' (from python) or any of the other weird things you get when there are multiple revisions of a single language spec. In essence it's not that the language is any more bloated than what is normal, or you would still be using KR C to get your work done, because you were afraid of bloat. -Yaakov Nemoy

On May 21, 2009, at 03:13 , Yaakov Nemoy wrote:
you would still be using KR C to get your work done, because you were afraid of bloat.
Actually you'd still be using BCPL. :) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
participants (6)
-
Brandon S. Allbery KF8NH
-
Don Stewart
-
Henning Thielemann
-
Jon Fairbairn
-
Vasili I. Galchin
-
Yaakov Nemoy