Data.Graph vs. FGL

I'm doing a little cleanup on FGL
(http://web.engr.oregonstate.edu/~erwig/fgl/haskell/).  Part of that
includes renaming modules to fit the hierarchical scheme; my plan was to
call the base Data.Graph.  Lo and behold, however, Data.Graph already
exists!  Could someone enlighten me on the reason what is now Data.Graph
was chosen over FGL for inclusion into the base library?

Also, given that Data.Graph already exists, what would be a good place for
FGL?  Data.Graph.FGL seems iffy for two reasons - it implies that it's a
subset of Data.Graph, and it still uses an acronym instead of a
descriptive name.

Thanks much!

Abe

Re: Data.Graph vs. FGL

On Tue, Dec 02, 2003 at 09:22:23AM -0500, Abraham Egnor wrote:
> I'm doing a little cleanup on FGL
> (http://web.engr.oregonstate.edu/~erwig/fgl/haskell/).  Part of that
> includes renaming modules to fit the hierarchical scheme; my plan was to
> call the base Data.Graph.  Lo and behold, however, Data.Graph already
> exists!  Could someone enlighten me on the reason what is now Data.Graph
> was chosen over FGL for inclusion into the base library?

It just got there first (and there were already three copies of it in
the fptools repository).  Could still be argued, though.

> Also, given that Data.Graph already exists, what would be a good place for
> FGL?  Data.Graph.FGL seems iffy for two reasons - it implies that it's a
> subset of Data.Graph, and it still uses an acronym instead of a
> descriptive name.

Data.Graph.Erwig or Data.Graph.Inductive?

Re: Data.Graph vs. FGL

hi,

Ross Paterson wrote:

>Data.Graph.Erwig or Data.Graph.Inductive?
>_______________________________________________
>  
>
i appreciate martin erwig's work on FGL,
but i think we should avoid naming libraries after the people that first 
designed them.
for a programmer, that naming scheme is not particularly enlightening
(they have to know the histiry of the development of the library to know 
why it has that particular name).
i'd much rather go with an abreviation, like FGL.
(these same comments go for the new naming scheme of the pretty library 
- i can never
remember if john hughes comes first or simon pj, and how much of their 
name should
i include in the import, so i stick with the good old "pretty")

and after all even microsoft didn't name their OS gates, they cleverly 
chose windows instead 

-iavor

--

-- 
==================================================
| Iavor S. Diatchki, Ph.D. student               | 
| Department of Computer Science and Engineering |

"Time Warp"

I spotted this and thought of some recent(ish) discussions...

[[
# "Time Warp"
New Scientist (11/22/03) Vol. 180, No. 2422, P. 30; Battersby, Stephen

An unusual practice of modern timekeeping is the insertion of a "leap 
second" into the calendar, which occurs less than once a year on average; 
this is done to make up for the discrepancy between international atomic 
time and solar time, which is changing as the Earth's rate of rotation 
gradually slows. Since the inception of leap seconds 30 years ago, 
coordinated universal time has lagged in fits and starts behind universal 
atomic time, and the situation has been complicated by the rollout of 
various technologies that have their own internal time frames. "With [these 
technologies] becoming more interactive, they need to be synchronized," 
states the Naval Research Laboratory's Ron Beard. Technologies ranging from 
GPS to air traffic control systems to the Internet to military systems are 
not designed with leap seconds in mind, which makes leap second insertion 
the responsibility of software engineers. This task is difficult enough, 
but complicating matters is the unpredictable nature of the Earth's slowing 
spin, a phenomenon attributed to as-yet-indeterminate internal forces; in 
fact, the planet's rotation has recently sped up, the result being no leap 
seconds for the last five years. Affected by this is Motorola's Oncore GPS 
receiver, which will add an extra day to the calendar just after midnight 
on the morning of Nov. 28, 2003. This extra day will only last for a 
second, but Motorola GPS product manager Dave Huntingford is worried that 
this could affect Nov. 28 cell phone bills and lead to lost revenues; 
Global Timing Services consultant William Klepczynski is even more 
concerned that such glitches, when combined with worker stress, could lead 
to disastrous errors in air traffic control. Beard and others think leap 

Re: "Time Warp"

This is a very common practice.  I've worked on several satellite 
projects and they all use leap seconds from time to time.

There are accepted ways in code to handle leap seconds.  If anyone 
needs details I can provide them.

On Dec 4, 2003, at 3:30 AM, Graham Klyne wrote:

> I spotted this and thought of some recent(ish) discussions...
>
> [[
> # "Time Warp"
> New Scientist (11/22/03) Vol. 180, No. 2422, P. 30; Battersby, Stephen
>
> An unusual practice of modern timekeeping is the insertion of a "leap 
> second" into the calendar, which occurs less than once a year on 
> average; this is done to make up for the discrepancy between 
> international atomic time and solar time, which is changing as the 
> Earth's rate of rotation gradually slows. Since the inception of leap 
> seconds 30 years ago, coordinated universal time has lagged in fits 
> and starts behind universal atomic time, and the situation has been 
> complicated by the rollout of various technologies that have their own 
> internal time frames. "With [these technologies] becoming more 
> interactive, they need to be synchronized," states the Naval Research 
> Laboratory's Ron Beard. Technologies ranging from GPS to air traffic 
> control systems to the Internet to military systems are not designed 
> with leap seconds in mind, which makes leap second insertion the 
> responsibility of software engineers. This task is difficult enough, 
> but complicating matters is the unpredictable nature of the Earth's 
> slowing spin, a phenomenon attributed to as-yet-indeterminate internal 

Abstract Data Structures

hi,

Abstract Data Types plus Data Structures gives Abstract Data Structures.

Divide by Conquer is a technique that every Computer Science Undergraduate
learns: to sort a listm sort each of its halves then merge.  This is what
I call "Computational Divide and Conquer" and it is an important algorithm
design strategy.  Algorithm Design and Programming were once considerd the
same and they were the heart of Computer Science.

Nowadays, we get our algorithms from libraries and are instead faced with
the complexity of programming applications.  It is essential that we
divide our programs into smaller parts and specify the contracts between
those parts.  This is what I call "Informational Divide and Conquer".

(The words "informational" vs "calculational" go back to Dijkstra who said
that a refinement step is good if it makes either "computational or
informational progress".  The former meaning decrease a loop or recursion
variant, the latter meaning to get simpler assertions.  I believe that the
Art or Science or whatnot of Programming will make a leap forward, when it
learns to profit from Dijkstras heritage.)

-- Abstraction in Programming firmly rests on the separation
-- of Specification and Implementation.  Implementations in functional
-- languages have always been on a "higher level", many of them
-- serving as their own specifications.  (Just take a look into
-- Haskell's Prelude and try to specify one of the functions.)  Due to
-- take higher-level of built-in abstraction, they have resisted for a
-- long time the use of programmer-defined abstraction, that is, the
-- separation of Specification and Implementation.  (Which is by the

Small SMTP client library

Sorry for my bad english.

If you find this limited module useful then you can insert in your project. It 
is very limited but it could be useful to send email message using insecure 
plain/login authentication. I have no time to extend it.

Regards,
Massimo Zaniboni.

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

FW: [Caml-list] Data structures and algorithms in Caml programs

Dear Haskell library folk

Here's an interesting survey about data structure libraries.  It's Caml
oriented, but very relevant to Haskell too.

Simon

-----Original Message-----
From: owner-caml-list <at> pauillac.inria.fr
[mailto:owner-caml-list <at> pauillac.inria.fr] On Behalf Of Diego Olivier
Fernandez Pons
Sent: 10 December 2003 14:43
To: caml-list <at> inria.fr
Subject: [Caml-list] Data structures and algorithms in Caml programs

    Bonjour,

I have reviewed 20 programs I think representative of Caml, trying to
investigate the usages and needs in data structures and algorithms.

http://www.edite-de-paris.com.fr/~fpons/Caml/Ressources/dsInCaml.html

The purpose is to have a more precise idea of what is really giving
trouble and help library designers to provide solutions that are
closely related to the programmers needs.

All comments are welcome including corrections and programmers
feedback on code design, etc.

Reviewed programs

RE: docon 2.06 triggers compiler bug

I assume that by "standard" library you mean "distributed with GHC and
Hugs".  The trouble with this approach is that it ties the package to
the GHC/Hugs release schedules, bloats the release size, and it
seriously increases our test burden before a release.

Our general plan is instead to try to make it much, much easier for
people to distribute packages for GHC, Hugs etc, which download and
install trivially easily.  It's possible today, but requires a lot of
work.  

That is exactly what the library infrastructure project is doing --
Isaac Jones is leading it, but I'm sure he could do with help.  Isaac,
how's it going?

Simon

| -----Original Message-----
| From: cvs-all-bounces <at> haskell.org [mailto:cvs-all-bounces <at> haskell.org]
On Behalf Of Peter Simons
| Sent: 16 December 2003 20:15
| To: cvs-ghc <at> haskell.org
| Subject: Re: docon 2.06 triggers compiler bug
| 
| Donald Bruce Stewart writes:
| 
|  > Conclusion: this program should go in the test suite!
| 
| Personally, I'd like to take it one step further: docon
| should go into the standard library. 
| 

Re: docon 2.06 triggers compiler bug

Simon Peyton-Jones writes:

 > I assume that by "standard" library you mean "distributed
 > with GHC and Hugs".

Actually, I meant "part of Prelude.hs". 

Shipping docon with the compilers would, no doubt, be quite
useful. But the much greater usefulness would come from
merging the design of the docon core library back into the
Haskell standard. In his documentation, Serge gives several
compelling reasons, why the class hierarchy he uses is more
accurate than the one provided by Haskell '98. (Especially
concerning deficits of the "Num" class.) Factoring these
changes back into the standard would IMHO be a good idea --
albeit, a lot of work.

Peter