Re: [Haskell-cafe] Re: looking for origin of quote on preprocessors and language design

2010-01-14 Thread Jason Dusek
2010/01/07 Maciej Piechotka :
> On Thu, 2010-01-07 at 13:32 +0100, Johannes Waldmann wrote:
> > Dear all,
> >
> > It's not exactly Haskell-specific, but ...
> > I am trying to track down the origin of the proverb
> >
> > "the existence (or: need for) a preprocessor
> > shows omissions in (the design of) a language."
> >
> > I like to think that in Haskell, we don't need
> > preprocessors since we can manipulate programs
> > programmatically, because they are data.
> >
> > In other words, a preprocessor realizes higher order
> > functions, and you only need this if your base language
> > is first-order.
> >
> > Yes, that's vastly simplified, and it does not cover
> > all cases, what about generic programming
> > (but this can be done via Data.Data)
> > and alex/happy (but we have parsec) etc etc.
>
> Not quite. While I agree that "the *frequent* need for a preprocessor
> shows omissions in (the design of) a language." it is not necessary the
> case. Preprocessor may be useful if:
>
> - there is a new beatyful feature in newer version of compiler but you
> still want to have backward compatibility.
> - there are compiler or platform dependant elements. For example if you
> write a driver in Haskell you may want to share code as much as possible
> but you need to know 1) the size of registers and 2) the platform you're
> writing as Windows have quite different API then Linux or BSD.
> - You need to enable/disable features at build-time. It is not frequent
> at closed-source system but it is frequent on OpenSource systems. For
> example I might need to have minimal program for embedded system but
> with full feature set it likly conquer the desktops
>
> in such cases it is easier/more efficient to just write
> #if (defined WINDOWS && BITS >= 64) || defined ALSA
> ...
> #elseif GHC_VERSION >= 061004
>
> #endif

  I think that pre-processing is an inevitable result of poor
  support for DSLs. When looking into embedded programming for
  the AVR family recently, I was surprised at the degree to
  which programmers rely on C macros; they're the only way they
  can get the expressiveness they want at a price they can
  accept.

  Haskell has strong support for embedded DSLs and the
  abstraction penalty is low so it's not hard to get away with
  just writing Haskell for things. Just the same, there are some
  aspects of Haskell syntax that make it horribly awkward for
  some applications. I would like to write all my shell scripts
  in Haskell -- especially those scripts that drive SSH
  connections or multiple external processes -- but the line
  noise penalty is pretty high right now. Using quasi-quotation
  -- a kind of pre-processor -- with a more shell-like set of
  shortcuts might be just the right thing.

  It's nice to reflect on the fact that Haskell offers a lot of
  flexibility for program transformation but is relatively safe
  from the incomprehensibility that results from the use of
  monkey patching in Ruby or macros in general.

--
Jason Dusek
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: looking for origin of quote on preprocessors and language design

2010-01-14 Thread Henning Thielemann
Maciej Piechotka schrieb:

> 
> Hmm. May I ask how to do for example something depending on POSIX or
> WinAPI? I am sorry but I cannot see how any of the above problems could
> be solved.

Sure, I choose different Hs-Source-Dirs for the different platforms.
Multiple Hs-Source-Dirs are merged.

Example:
   http://hackage.haskell.org/packages/archive/sox/0.1/sox.cabal

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: looking for origin of quote on preprocessors and language design

2010-01-13 Thread Maciej Piechotka
On Wed, 2010-01-13 at 22:42 +0100, Henning Thielemann wrote:
> Maciej Piechotka schrieb:
> >
> > Not quite. While I agree that "the *frequent* need for a preprocessor
> > shows omissions in (the design of) a language." it is not necessary the
> > case. Preprocessor may be useful if:
> >
> > - there is a new beatyful feature in newer version of compiler but you
> > still want to have backward compatibility.
> > - there are compiler or platform dependant elements. For example if you
> > write a driver in Haskell you may want to share code as much as possible
> > but you need to know 1) the size of registers and 2) the platform you're
> > writing as Windows have quite different API then Linux or BSD.
> > - You need to enable/disable features at build-time. It is not frequent
> > at closed-source system but it is frequent on OpenSource systems. For
> > example I might need to have minimal program for embedded system but
> > with full feature set it likly conquer the desktops
> >   
> Many of these problems are solved by preprocessor intervention in C/C++, 
> but there is often no need to do so. You could also write system 
> dependent modules, where the right module for your system is included by 
> the build system. I hope the build system does not count as a 
> preprocessor. In Haskell it is however still no fun to support multiple 
> versions of the base libraries, not to speak of different compilers - 
> and their set of libraries.
> 
> Unfortunately, the original question is still not answered.
> 

Hmm. May I ask how to do for example something depending on POSIX or
WinAPI? I am sorry but I cannot see how any of the above problems could
be solved.

Regards


signature.asc
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: looking for origin of quote on preprocessors and language design

2010-01-13 Thread Henning Thielemann

Maciej Piechotka schrieb:


Not quite. While I agree that "the *frequent* need for a preprocessor
shows omissions in (the design of) a language." it is not necessary the
case. Preprocessor may be useful if:

- there is a new beatyful feature in newer version of compiler but you
still want to have backward compatibility.
- there are compiler or platform dependant elements. For example if you
write a driver in Haskell you may want to share code as much as possible
but you need to know 1) the size of registers and 2) the platform you're
writing as Windows have quite different API then Linux or BSD.
- You need to enable/disable features at build-time. It is not frequent
at closed-source system but it is frequent on OpenSource systems. For
example I might need to have minimal program for embedded system but
with full feature set it likly conquer the desktops
  
Many of these problems are solved by preprocessor intervention in C/C++, 
but there is often no need to do so. You could also write system 
dependent modules, where the right module for your system is included by 
the build system. I hope the build system does not count as a 
preprocessor. In Haskell it is however still no fun to support multiple 
versions of the base libraries, not to speak of different compilers - 
and their set of libraries.


Unfortunately, the original question is still not answered.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Re: looking for origin of quote on preprocessors and language design

2010-01-07 Thread Maciej Piechotka
On Thu, 2010-01-07 at 13:32 +0100, Johannes Waldmann wrote:
> Dear all,
> 
> It's not exactly Haskell-specific, but ...
> I am trying to track down the origin of the proverb
> 
> "the existence (or: need for) a preprocessor
> shows omissions in (the design of) a language."
> 
> 
> I like to think that in Haskell, we don't need
> preprocessors since we can manipulate programs
> programmatically, because they are data.
> 
> In other words, a preprocessor realizes higher order
> functions, and you only need this if your base language
> is first-order.
> 
> Yes, that's vastly simplified, and it does not cover
> all cases, what about generic programming
> (but this can be done via Data.Data)
> and alex/happy (but we have parsec) etc etc.
> 
> Best regards, J.W.
> 

Not quite. While I agree that "the *frequent* need for a preprocessor
shows omissions in (the design of) a language." it is not necessary the
case. Preprocessor may be useful if:

- there is a new beatyful feature in newer version of compiler but you
still want to have backward compatibility.
- there are compiler or platform dependant elements. For example if you
write a driver in Haskell you may want to share code as much as possible
but you need to know 1) the size of registers and 2) the platform you're
writing as Windows have quite different API then Linux or BSD.
- You need to enable/disable features at build-time. It is not frequent
at closed-source system but it is frequent on OpenSource systems. For
example I might need to have minimal program for embedded system but
with full feature set it likly conquer the desktops

in such cases it is easier/more efficient to just write
#if (defined WINDOWS && BITS >= 64) || defined ALSA
...
#elseif GHC_VERSION >= 061004

#endif

Regards


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe