Ian Zimmerman [EMAIL PROTECTED] wrote,
Mark Ultimately, it comes down to a question of what you're trying to
Mark achieve. Do you envisage Haskell as an elegant scripting
Mark language that competes with perl and ruby for quick but useful
Mark hacks? Or do you think it might better serve
Claus Reinke [EMAIL PROTECTED] writes:
Haskell definitely supports abstraction and composition, so we can
factor out application aspects (not just text) that need localisation,
and link them (dynamically?) with the main parts of our applications.
Some systematic approach would be useful,
On Wed, Feb 13, 2002 at 08:42:09AM -0800, Jeffrey R Lewis wrote:
The point about same support in all implementations is of course a good one.
Thomas and I are the culprits who put here docs in hugs in the first place.
However, it is just as easy to support here docs using a pre-processor.
{-
Unlike my rough proposal, one should aim for a combination of
(mostly) in-Haskell implementation and (some) pre-processing. As
Thomas Nordin has pointed out to me in private email, Hugs (Dec
2001) already supports this (module lib/hugs/Quote.hs and flag +H).
The real trick is to have
| Usually, I wouldn't make such a fuss, but here documents are really
| not some new and experimental feature. They're an old hat, and a
| very useful hat. The only question is how to integrate them into the
| rest of Haskell.
At a time when many developers pay careful attention to
Mark Ultimately, it comes down to a question of what you're trying to
Mark achieve. Do you envisage Haskell as an elegant scripting
Mark language that competes with perl and ruby for quick but useful
Mark hacks? Or do you think it might better serve as a platform for
Mark writing significant
| ..[here documents: .. old and very useful hat]..
At a time when many developers pay careful attention to
internationalization (I18n), which requires careful
separation of program text (functionality) and user text
(display), a feature that instead ties them more closely
together seems
Does anybody with their elbows in the
code think variable interpolation and/or
multi-line strings are good/doable ideas?
Would this be the sort of change one could make
without a lot of previous familiarity with
the implementation of Hugs/Ghc?
It would be a *signifigant* boon to those
of us
From: Joe [EMAIL PROTECTED]
Does anybody with their elbows in the
code think variable interpolation and/or
multi-line strings are good/doable ideas?
Can't say I have my elbows in the code, but I think that
multi-line strings could be useful. I'm not sure what I
think about variable
Does anybody with their elbows in the
code think variable interpolation and/or
multi-line strings are good/doable ideas?
Would this be the sort of change one could make
without a lot of previous familiarity with
the implementation of Hugs/Ghc?
It would be a *signifigant* boon to those
of
On Wed, 13 Feb 2002, David Feuer wrote:
It would be a *signifigant* boon to those
of us trying to get haskell into organizations
by using it as maintainable perl/sh, and
Haskell is not a maintainable perl/sh. It is not a good
language for simple shell scripts, and is not good for
On Wednesday 13 February 2002 06:36 am, C.Reinke wrote:
Does anybody with their elbows in the
code think variable interpolation and/or
multi-line strings are good/doable ideas?
Would this be the sort of change one could make
without a lot of previous familiarity with
the
hugs and ghc. With hugs, I use the builtin feature, of course. With GHC, we
just use a pre-processor. This is a bit awkward with GHC 5.02 and earlier
versions, but starting with 5.03, GHC now has a proper interface for hooking
in a pre-processor (don't know the details, bug Sigbjorn
13 matches
Mail list logo
