> Personally I find the convention of using `a', `b', and `c' for type
> variables to be a poor one. I much prefer using `t' (if there's
> only one) or `t1', `t2', ... (if there's more than one).
> I find that for me this makes it much easier to read type declarations,
> because names like `a', `
> So, the name of a type is always at least a full word, as are the names of
> specific functions. But type variables are almost always single
> characters, and distinct from the names of any type. Conventionally, they
> are also usually "a", "b", and "c", although "m" is for monad.
> Convention
On Fri, 11 Jun 1999, Malcolm Wallace wrote:
> Well, compiler-independent is possible (e.g. hmake extracts
> dependencies from any Haskell sources, regardless of compiler.)
> However, language-independent is much more difficult. How could one
> tool deal with all of C, C++, Haskell, and LaTeX? S
> >I disagree, small scripts spend most of the time doing I/O if I don't
> >understand how to do that I'm not able to even write the most simple
> >things. This is eg. true for my cat ...
>
> I disagree. You need to know more about Functional Programming
> (and also the Haskell type system and it
David Tweed writes:
> > $ gcc -M main.c >>Makefile
> > $ ghc -M Main.hs >>Makefile
> > $ hmake -M MyProg >>Makefile
>
> Since several people have pointed out the -M option for gcc I'd better
> explain that, for reasons of no interest to Haskell users, when tackling
> _C++_ it pro
[drifting off-topic]
On Fri, 11 Jun 1999, Malcolm Wallace wrote:
> David Tweed writes:
>
> > I think it'd probably better software engineering to split the two tasks.
> > Other than a rather nasty syntax, make does what it sets out to do quite
> > well: using specified dependencies and time-st
On Thu, 10 Jun 1999, Craig Dickson wrote:
> programming, especially lazy functional programming. If it seems desireable
> to re-implement a standard Unix utility in Haskell, I suggest 'make'. One
> could even design and implement a 'make' that would know all about Haskell
> modules, and parse th
Simon Peyton-Jones <[EMAIL PROTECTED]> writes:
> What I have not done (any volunteers) is to export these rules, or
> the function definitions to a thm prover.
I am in the course of exporting function definitions
(and later probably also rules)
to the term graph transformation system HOPS
(
Jonathan King writes:
> So, the name of a type is always at least a full word, as are the names of
> specific functions. But type variables are almost always single
> characters, and distinct from the names of any type. Conventionally, they
> are also usually "a", "b", and "c", although "m" is
Jonathan King wrote:
> > transformListElems :: (elem -> elem') -> List elem -> List elem'
> > transformListElems transform Nil = Nil
> > transformListElems transform (Cons elem elemRest) =
> > Cons (transform elem) (transformListElems transform elemRest)
>
> Well, the second version does
On Fri, 11 Jun 1999, Craig Dickson wrote:
> I don't see that underscores serve readability in the same way as Hungarian
> notation purports to (unless the Eiffel people claim that underscores
> somehow convey type information?), so I don't see a conflict here. One could
> easily use both, e.g.
Christian Sievers <[EMAIL PROTECTED]> wrote:
> I'm in trouble when it comes to @-patterns: is xs@(x:_) acceptable?
I'm sure I've used that, or something quite like it. xs is the whole list,
and x is its head.
> I've seen the (x:xs) (or whatever letter you want, BTW I'd use (f:fs)
> for a list o
On Fri, 11 Jun 1999, Jan Skibinski wrote:
>
>Keith Wansbrough <[EMAIL PROTECTED]>,
> >
> > [[EMAIL PROTECTED] wrote stuff but got snipped]
> > >
> > > [stuff about whether there was a Haskell coding convention snipped]
> >
> > I think this kind of thing is valuable... Hungarian notation [1]
>
> I think this kind of thing is valuable... Hungarian notation [1]
> serves the same purpose in Windows C / C++ programming. It *is*
> valuable having canonical variable names for most situations; it reduces
the
> intellectual load on the (human) reader of the code... you don't have to
> chec
Jan Skibinski <[EMAIL PROTECTED]> wrote:
> But there are some stylistic camps, such as Eiffel's, that
> prefer names with underscores rather than Hungarian notation
> - claiming exactly the same reason: better readability. :-)
I don't see that underscores serve readability in the same way as Hun
On 10-Jun-1999, D. Tweed <[EMAIL PROTECTED]> wrote:
> On Thu, 10 Jun 1999, Craig Dickson wrote:
>
> > If it seems desireable
> > to re-implement a standard Unix utility in Haskell, I suggest 'make'. One
> > could even design and implement a 'make' that would know all about Haskell
> > modules, an
> Idea 1:
> Export Haskell declarations to a theorem prover, such as HOL
> or PVS. Then
> permit the user of the theorem prover to state and prove
> properties of the
> Haskell program, using the exported definitions.
>
> Ideas 2:
>
> There was recently a discussion about adding "rules" to
>
> Here is my situation: I have a state monad. It seems to me that
> if states are built out of lazy types, then there may be many
> states all live at the same time, thus blowing up the space.
> But deep in my state data types, I have strings. Also some
> monad operations return strings. So I
18 matches
Mail list logo
