I typically start with a list of the types I want, then the minimal list
of type signatures. Ideally, it should be possible to write an
arbitrarily large set of programs in the given application domain by
composing this initial list of functions (so the data type can be
specified abstractly, if
Hello Donn,
Wednesday, November 7, 2007, 10:26:20 PM, you wrote:
> Now it's not like I can't imagine it working better - it may be a little
> fragile, for one thing - but I have wondered what facilities a Haskell
> design could have drawn on to de-couple implementation components like that.
:)))
Hello Levi,
Thursday, November 8, 2007, 2:06:14 AM, you wrote:
> Now I have to learn how to select the appropriate abstractions in Haskell.
> e.g.,
> selecting between a variant type or type class is often a tricky one for me.
that's easy part. i never have need to use type classes in applicati
Tim Docker wrote:
levi.stephen wrote:
My concern (which may be inexperience ;) ) is with the monads here
though. What if I hadn't seen that the IO monad (or any other Monad)
was going to be necessary in the type signatures?
You'd have some refactoring to do :-) But actually, it's not possible
On Thu, 2007-11-08 at 13:21 +1100, Tim Docker wrote:
> levi.stephen wrote:
> > My concern (which may be inexperience ;) ) is with the monads here
> > though. What if I hadn't seen that the IO monad (or any other Monad)
> > was going to be necessary in the type signatures?
>
>
> You'd have some re
levi.stephen wrote:
> My concern (which may be inexperience ;) ) is with the monads here
> though. What if I hadn't seen that the IO monad (or any other Monad)
> was going to be necessary in the type signatures?
You'd have some refactoring to do :-) But actually, it's not possible
to create an i
Tim Docker wrote:
levi.stephen wrote:
I have similar questions about Haskell abstracting away
implementations behind interfaces as well. I have become
used to an approach where I will not worry about
databases/persistence when beginning. I will create an
interface to a database layer (e.g., save
On Wed, 7 Nov 2007, Justin Bailey wrote:
> > So I'm the one user in a thousand that will want to provide my own I/O
> > functions, for example. In the old world, I guess I would be looking
> > for some extended API where my I/O functions are parameters to the "open"
> > or "init" function, and th
levi.stephen wrote:
> I have similar questions about Haskell abstracting away
> implementations behind interfaces as well. I have become
> used to an approach where I will not worry about
> databases/persistence when beginning. I will create an
> interface to a database layer (e.g., save(object),
Donn Cave wrote:
But in the specific matter I'm wrestling with, the Java library's OOP
model is, to its credit, allowing me to do some things. I'm using their
standard LDAP client library, but swapping in my own function to read
X509 certificates for the SSL. Actually, swapping in my own SSL s
Bulat Ziganshin wrote:
Hello Andrew,
Tuesday, November 6, 2007, 10:55:58 PM, you wrote:
for me, abstraction is anything that i want to be an abstraction. i
just write code in the close-to-natural language and it becomes
Haskell program when appropriate syntax applied.
Well, in my experience
> So I'm the one user in a thousand that will want to provide my own I/O
> functions, for example. In the old world, I guess I would be looking
> for some extended API where my I/O functions are parameters to the "open"
> or "init" function, and the IMAP functions take over from there. In a
> mor
On 7 Nov 2007, at 11:26 AM, Donn Cave wrote:
I have been working on a little Java project lately at work, by way
of an introduction to the language, and naturally I often have cause
to regret that it isn't Haskell instead.
But in the specific matter I'm wrestling with, the Java library's OOP
m
I have been working on a little Java project lately at work, by way
of an introduction to the language, and naturally I often have cause
to regret that it isn't Haskell instead.
But in the specific matter I'm wrestling with, the Java library's OOP
model is, to its credit, allowing me to do some th
Hello Andrew,
Tuesday, November 6, 2007, 10:55:58 PM, you wrote:
>> for me, abstraction is anything that i want to be an abstraction. i
>> just write code in the close-to-natural language and it becomes
>> Haskell program when appropriate syntax applied.
> Well, in my experience, figuring out ju
Bulat Ziganshin wrote:
Hello Andrew,
Tuesday, November 6, 2007, 9:34:34 PM, you wrote:
It used to be easier with OOP. I'm still not quite sure how to pick the
best possible abstractions in an FP context...
for me, abstraction is anything that i want to be an abstraction. i
just write
On Tue, 2007-11-06 at 10:32 +1030, Levi Stephen wrote:
> Hi,
>
> I'm was wondering how most people work during when designing a functional
> program. Do you create data structures/types first? Do you work from some
> type
> signatures?
As others have mentioned: both. But there's a third thing
Hello Andrew,
Tuesday, November 6, 2007, 9:34:34 PM, you wrote:
> It used to be easier with OOP. I'm still not quite sure how to pick the
> best possible abstractions in an FP context...
for me, abstraction is anything that i want to be an abstraction. i
just write code in the close-to-natural l
Levi Stephen wrote:
Hi,
I'm was wondering how most people work during when designing a
functional program. Do you create data structures/types first? Do you
work from some type signatures?
In *any* programming language, my workflow usually goes like this:
1. Think about it for a minute or t
Levi Stephen wrote:
Hi,
I'm was wondering how most people work during when designing a
functional program. Do you create data structures/types first? Do you
work from some type signatures?
For example, take a blog. Is the first step likely to be something like:
data BlogEntry = BlogEntry {
On Tue, 2007-11-06 at 10:32 +1030, Levi Stephen wrote:
> Hi,
>
> I'm was wondering how most people work during when designing a functional
> program. Do you create data structures/types first? Do you work from some
> type
> signatures?
>
> For example, take a blog. Is the first step likely to
On 11/5/07, Levi Stephen <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm was wondering how most people work during when designing a functional
> program. Do you create data structures/types first? Do you work from some type
> signatures?
>
> For example, take a blog. Is the first step likely to be somethi
Hello Levi,
Tuesday, November 6, 2007, 3:02:49 AM, you wrote:
> I'm was wondering how most people work during when designing a functional
> program. Do you create data structures/types first? Do you work from some type
> signatures?
not first nor second. i write function bodies, then declare
app
Hi,
I'm was wondering how most people work during when designing a functional
program. Do you create data structures/types first? Do you work from some type
signatures?
For example, take a blog. Is the first step likely to be something like:
data BlogEntry = BlogEntry { title::String,content
24 matches
Mail list logo