Re: [Haskell] Beyond ASCII only editors for Haskell

2005-05-23 Thread Reginald Meeson

Mads --

Eons ago, colleagues and I put together a primitive data flow diagram
editor and generated functional code for the functions users wired
together.  One of the things we learned was that people would happily
wire together diagrams with state components that could not be
translated because they did not represent functions.  (Two different
data flow paths sharing the same state creates obvious race conditions,
but that's what some people wanted to draw.)

It was an interesting exercise to build the tool, but I don't think
it gave users any great advantage.  Perhaps is was a shortcoming of
the tool, which was little more than a prototype.  However, the
informal nature of data flow diagramming at that time seemed to be
out of synch with the rigor needed for programming.  Good luck with
your search -- it may be a good time to try it again.

-- Reg



Hi

One of Haskell's advantages is that it is very suitable as an executable
specification language. Which is also claimed on
http://www.haskell.org/aboutHaskell.html:

"Much of a software product's life is spent in specification, design
and maintenance, and not in programming. Functional languages are superb
for writing specifications which can actually be executed (and hence
tested and debugged). Such a specification then is the first prototype
of the final program."

also on the same page:

"Haskell, a purely functional programming language, offers you:
...
* A smaller "semantic gap" between the programmer and
the language.
"

But if I were to specify a program (in a non-executable language) or if
I were to write some function on a blackboard, I would not be restricted
to only ASCII characters. For example, I would not write 'sqrt 2' but I
would write a square root symbol with 2 underneath. Likewise, I would
not write '2 ^ 5', but I would write a 2 with a 5 raised upwards to the
right of the 2. Then why are we stuck with the mono-spatial ASCII based
editors in Haskell? Why is it not possible to make Haskell program look
similar to ordinary math? (also when writing those programs and not just
afterward in some Latex formatted paper).

Also, programmers often use diagrams as specification. As Andrew Bromage
says it in http://haskell.org/~shae/pseudocode1.pdf:

"Mostly, I strongly suspect that most code of this type is not written,
but rather it's translated into. I tend to see many uses of "point-free
style" in the same light. It's also one of the reasons why I've resisted
using arrows: You don't program in arrow style; you program in diagrams
on paper, then translate that into arrow style."

This makes me think that our diagrams should be compilable and thus
executable? These diagrams could be embedded in our editor and
intermixed with ordinary code.

I have looked for the type of editor roughly outlined above, but found
nothing. If anybody have some links to projects, which is related to
these kind of thoughts please let yourself be heard. Also, of cause,
comments are most welcome.

--
Mads Lindstrøm <[EMAIL PROTECTED]>

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



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


Re: ICFP programming contest

1999-09-17 Thread Reginald Meeson

>Lennart Augustsson wrote:
>
>>...
>
>Ooops, I miscounted.  It's 376 lines of Haskell; still 137 in the optimizer.
>(Not much productivity, just 1 line/minute.)
>

It appears Lennart is exercising his well-deserved bragging rights.  :^)
More power to him.  Congratulations Lennart, and to all the other
contestants as well!  (I chickened out.  Wisely, I think.)  Thanks
also to those who set up the contest.

I would be interested in hearing from other contestants about how they
think their programming language helped (or didn't help) them solve
the problem.  What language features were most helpful?  Did anything
particular get in the way?  How much code did solutions take in other
languages?  Any smaller than 376 lines?  Any teams more productive than
1 line/minute?

-- Reg





Re: Monad question

1999-04-22 Thread Reginald Meeson

This little problem raises two challenges for compiler developers:
(a) improving diagnostic messages (a perennial issue), and (b) (semi)
automating error correction.  In this case the diagnostic message
is pretty good, except that is doesn't indicate where the IO term
is or where the [] term is that doesn't match.  This is the critical
piece of information Malcolm added to explain the problem.

It seems that lifting would be a natural extension to the type
unification process to allow automating "corrections".  When you
find several possible lifting functions, of course, you are in
trouble.  But then you could add that information to the diagnostic
message.  This may be trying too hard to help the fat fingered
programmer (aka, yours truly) who simply entered an incorrect
expression.  Reactions anybody?

Thanks to Malcolm and the other responders for such clear explanations
and clean solutions.

-- Reg

>> getDirectoryContents "." >>= filter (\(x:_) -> x /= '.');
>> [65] Cannot unify types:
>> Prelude.IO
>> and (Prelude.[])
>
>The problem is that `filter's result type is [a], not
>(IO [a]) which its use as an argument to >>= requires.
>The fix is easy: lift its result into the monad (using `return').
>
>  getDirectoryContents "." >>= return . filter (\(x:_) -> x /= '.')
>





Re: Function denotations

1993-11-18 Thread Reginald Meeson


Reply to:   RE>Function denotations
I'm sure many people would find printable function representations
useful.  There are at least three versions of every function I've ever
written: the function I meant (fm), the function I wrote (fw), and
the function the compiler/interpreter produced/executed (fx).  When
tests show that fx /= fm, some visibility into fx can be most helpful.
Even if the correspondence between fw and fx is a stretch, knowing
more about fx often points to the problem with fw.

This issue isn't really one of language definition, though.  It seems
to me it's an issue for programming support environments.  I don't
know of any language standard that includes requirements for
debugging tools.  Any implementers willing to give this a whirl?







Re: Arrays and general functions

1992-09-08 Thread Reginald Meeson

Interesting discussion, but it seems to me that Haskell already
provides the best of both worlds, namely

  a. Efficient implementation of arrays as data objects, with indexing
 as a projection function; and

  b. Definition of functions with (Ix a) domains by indexing an array
 behind the scenes or by any other rule.

Arrays satisfy the needs of an important user community.  Is there
something more needed to satisfy the general-function community?