[Haskell] Re: ANNOUNCE: container-classes-0.0.0.0
On 18 July 2010 23:35, Ivan Lazar Miljenovic wrote: > * Someone's asked me why I don't define a Traversable-like class. The > reason is is that I haven't gotten around to it yet ;-) (as well as a > great many other things). Ugh, I got Traversable mixed up with Foldable (I didn't get enough sleep on the weekend and I should hit the sack now). I've integrated fold right into the definition of Container, and everything else comes straight from that so I didn't see the point of making an explicit sub-class (or a super-class, take your pick) just for that. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: "New FGL" naming survey
Thank you for all the people who have voted; we so far have 42 results in about 12 hours. Some indication of the results so far: * 62% prefer inductive-graphs * 62% have indicated that they use fgl or do some graph-related stuff (no correlation, just an interesting coincidence; I have not as yet done the number crunching to tell what the most popular name is for people that actually use fgl or other graph stuff). * Someone stated that ponies smell sweaty... not sure how that's relevant, but OK. * At least two people prefer the new name as it isn't an acronym (one because acronyms aren't needed and the term functional is redundant, the other because the term "graph" isn't directly in the package name). * Martin Erwig himself said that he thinks we should keep using the name "fgl". So, keep the votes coming in (I actually didn't expect this many already)! On 14 July 2010 00:24, Ivan Lazar Miljenovic wrote: > Whether or not the new FGL that Thomas Bereknyei and I are working on > should keep the name was a semi-hot issue when we first mentioned the > fact that we were working on a new version about a month ago. As such, > I've created a survey here to try and find out what the Haskell > community overall thinks we should call it: > https://spreadsheets.google.com/viewform?formkey=dGpzMmFnUWY3Uktodk5wdHlLQk5kT1E6MA > > More info can be found on the actual survey page. > > -- > Ivan Lazar Miljenovic > ivan.miljeno...@gmail.com > IvanMiljenovic.wordpress.com > -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Possible solution to the FGL naming/compatability issue
Last night (AEST), Edward Kmett semi-convinced (in the sense that I'm not sure whether his examples are really those that someone would want/need or just thinking of possible future problems) me that some users may have a need for FGL to keep having explicit graphs with kind * -> * -> *. With his prompting, I may have a possible solution: duplicate the classes. We would have an InductiveGraph class (call it the parametric version) that requires graphs to have kind * -> * -> *, and then another class (call it the extended version) that removes this restriction. The parametric version would be closer to a drop-in replacement to the current FGL setup (see below for more details) and the extended one would provide all of the functionality requested, with some kind of semi-automatic lifting/unlifting for graph types that are instances of both. Now, this parametric version will still not be a drop-in for the current FGL, for several reasons: * I want to have one overall InductiveGraph class rather than two separate Graph and DynGraph classes * Context will still be an actual data type rather than a 4-tuple and LEdge would be come (Edge, Label) rather than (Node, Node, Label) [I'm still debating whether to keep Edge as a datatype as needed for the Type Familiy version or if it should just be a tuple). * Some function names will be changed (e.g. fromContexts rather than buildGr). * The Data.Graph.Inductive.Query stuff is going to be split out into its own separate library, the Data.Graph.Inductive.Graphviz stuff is going to be removed, etc. * With the removal of the sub-libraries, I'm seriously considering moving the class definitions from Data.Graph.Inductive.Graph to just Data.Graph.Inductive. There are also some caveats/design decisions with this solution: * There will obviously be duplication. With that said, do we try to make the two classes semi-drop-ins (same class name, methods, etc. but with different types) or think up new method names for the extended version? * How transparently can/will we make the lifting/unlifting? * If we want the parametric version to still have the ability to specify a custom node type, then it will still need either MPTCs + fundeps or Type Families (i.e. extensions); otherwise we stick with the current "type Node = Int" (or maybe replace it with some opaque abstract type down the track as suggested by Heinrich Apfelmus). * If we want to provide the ability to restrict the types of the labels in the parametric version, then we would need MPTCs (Type Families won't work since the label types won't be part of the class definition then unless we use MPTCs, and in that case there's not really any point in using Type Families). Thus we once again need extensions. * My semi-end goal is to build a proper hierarchy of graph types/libraries, such that the only thing FGL provides is the extra aspect/concept of inductive graphs. If we extend this parametric vs extended split down to the set of base graph classes, then we're going to have even more duplication and this kind of setup (where "Foo depends on Bar" means "class (Bar a) => Foo a where ..."): - fgl-parametric will depend on graph-parametric - fgl-extended will depend on graph-extended - There will be lifting/unlifting between graph-parametric and graph-extended - There will be lifting/unlifting between fgl-parametric and fgl-extended As such, an FGL graph of kind * -> * -> * being treated as an extended graph will have two possible ways (depending on the function in question) will have two graph hierarchies two choose from, and two possible points at which it can be lifted/unlifted (at the graph level and the fgl level). This could get confusing. That said, there is one other benefit of this parametric vs extended split: the types of the mapping functions in http://code.haskell.org/FGL/fgl/Data/Graph/Inductive/Graph.hs won't be as weird... So, what are people's thoughts/opinions on this kind of setup? Note that I haven't started coding it yet, so I'm not sure how well it will work in practice... -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Please check your dependencies on fgl
Thomas Bereknyei are currently re-writing fgl (just about completely from scratch) and we plan to make an initial release to get feedback on the API in the next few weeks. However, I'm sending this email out now to warn people that I highly doubt any code that was written for the current version of fgl (http://hackage.haskell.org/package/fgl-5.4.2.2) will work with the new version. As such, if your code uses fgl you should ensure that the specification of the package in your .cabal file has an explicit upper bound (or indeed just set "fgl == 5.4.2.2") to avoid any problems when we release 6.0.0.0 (we're trying to avoid the problems that plagued KDE-4 by not claiming in the slightest that the initial few versions are intended for end users). I have already directly emailed the maintainers of any and all packages I could find on Hackage (using Roel van Dijk's wonderful reverse-dependency mirror at http://bifunctor.homelinux.net/~roel/hackage/packages/hackage.html), but just in case I've missed one or there's an as-yet-unreleased package somewhere in the works, here is the official "heads up". -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Package removal
On 14 May 2010 12:44, Yang Zhang wrote: > How do ghc users on Linux (esp. Debian/Ubuntu) systems remove > packages? I uninstall the system package I used to install that package. However, this doesn't work for cabal-install... > AFAICT there's only cabal unregister, Do you mean "ghc-pkg unregister"? > and no way to remove files but manually, which is tricky when these packages > are > interspersed with other files in /usr/local. I found some old mailing > list threads mentioning that this is an open issue, but as I'm > currently facing this, I'm wondering if there's been any news on this > front. Nope. Maybe using something like stow with this if you're installing it into /usr/local anyway... -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: Introducing Sifflet, visual functional programming language
On 14 May 2010 11:50, Gregory D. Weber wrote: > Introducing Sifflet -- version 0.1.5, first public release! > > Sifflet is a visual, functional programming language. > Sifflet programmers define functions by drawing diagrams. > Sifflet shows how a function call is evaluated on the diagram. > It is intended as an aid for learning about recursion. So is Sifflet meant to be a full-featured programming language used for "real world" programs? If so, how well does it scale? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: ANNOUNCE: graphviz 2999.9.0.0
A few things I forgot to mention in my haste to get this out: 1) I was planning on having a tutorial-style blog post where I'd use graphviz to parse an manipulate the output "ghc-pkg dot"; however I've been busier than I expected recently and figured it'd be better to get this release out and do this later. 2) The website was developed with the help of John MacFarlane; at the moment I'm using the CSS he uses for Pandoc's homepage, but I plan on updating that during the week (again, better to get it out now and fix it later). And with that, I need to sleep. Having a public holiday to get this finished in was nice, but it didn't help with my sleep deprivation :s On 26 April 2010 23:46, Ivan Lazar Miljenovic wrote: > > I'm pleased to announce the latest version of my graphviz library that > provides Haskell bindings to the Graphviz graph visualisation suite. > > There are numerous changes in this release, the most important of which > are: > > * graphviz now has an FAQ and an improved README as well as its own > homepage: http://projects.haskell.org/graphviz/ (as prompted by Eric > Kow). > > * Add support for record labels; values are automatically > escaped/unescaped. The `Record` and `MRecord` shapes have been > added for use with these labels. Requested by Minh Thu and Eric > Kow. > > * Add support for HTML-like values (this replaces the wrong and > completely broken URL datatype). Strings are automatically > escaped/unescaped. > > * Various parsing improvements (including a slight parsing speed > increase!). > > In particular, graphviz is now able to parse almost all Dot graphs found > on my system (including samples shipped with Graphviz, Linux kernel > documentation and various other package documentations). A list of the > breakages and why: > > * /usr/share/sgml/docbook/xsl-stylesheets/roundtrip/template.dot seems > to be a binary file and thus can't be read. > > * /usr/share/graphviz/graphs/directed/Latin1.gv uses Latin1 encoding; at > the moment graphviz uses the system's locale encoding (or whatever GHC > < 6.10 defaults to). > > * /usr/share/doc/boost-*/html/libs/graph/example/graphviz_test.dot > (various boost versions) has subgraphs in edges; graphviz currently > can't cope with these. > > * > /usr/src/linux-2.6.33-gentoo-r1/Documentation/blockdev/drbd/drbd-connection-state-overview.dot > uses incorrect syntax for the "minlen" attribute (it is meant to be an > integer but actually contains a floating point value). > > The plans for the next release (which I don't plan on even starting for > a while) are to focus on improving printing and parsing performance, > using a state-based printer and parser (as part of Dot syntax is > state-based) and force usage of UTF-8 (via text or utf8-string). > > -- > Ivan Lazar Miljenovic > ivan.miljeno...@gmail.com > IvanMiljenovic.wordpress.com > -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANN: Try Haskell! An interactive tutorial in your browser
On 1 March 2010 11:21, Hector Guilarte wrote: > I tried it and it worked perfectly, however I tried it again 45 minutes > later (about 15 minutes ago) and when I pressed Enter nothing happened. I > couldn't enter any expressions. The only expression I could enter was help > Hector "stepN" works for me as well (with N \in Z^+). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: SourceGraph-0.1 and Graphalyze-0.3
I've now uploaded my SourceGraph program to Hackage [1]. It's rather simple at the moment, but if you pass in the .cabal file as a parameter (e.g. run it as "SourceGraph Foo.cabal"), it will create in the same directory as the .cabal file a Directory called "SourceGraph" that contains an html report of some basic graph-theoretic analysis of your code. The output format isn't ideal, but it should serve it's purpose for now (I'll fix it up and actually make it usable once my Thesis has been handed in). What I'd appreciate if people could try it out and tell me if there's any code, etc. that it can't parse. At the moment, it ignores all Data-based functions (e.g. class and instance declarations as well as record functions) and only looks at "stand-alone" functions (i.e. normal functions). SourceGraph requires version 0.3 of my Graphalyze library (version 0.2 added the reports in, but had some bugs that 0.3 fixes). [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/SourceGraph -- Ivan Lazar Miljenovic [EMAIL PROTECTED] IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: Graphalyze-0.1
I'd like to announce the initial release of my graph-theoretic analysis library, Graphalyze [1], the darcs repo for which is also available [2]. This is a pre-release of the library that I'm writing for my mathematics honours thesis, "Graph-Theoretic Analysis of the Relationships in Discrete Data". I'll also be releasing a tool that uses this library to analyse the structure of Haskell code, that I'm tentatively calling SourceGraph. As it stands, the library has a number of algorithms included, some of which I've developed from scratch (e.g. clique finder), and others are implementations of published algorithms (mainly the two clustering algorithms). The code is meant to be more readable than efficient, and I wanted to explore ways of developing algorithms that match more closely the way graphs work (which makes FGL a much nicer fit than matrix-based or list-based graph data structures). This library is only a pre-release, as whilst everything in there works (at least it does for me), I'd like to get some feedback from the community, especially since this is my first ever released solo piece of code (I've coded assignments, and worked on projects with others, but have never released anything that I've been solely responsible for before). In particular, have I written the .cabal file correctly? Also, I'd like advice on something else: the part of the library that I'd like to develop still is the reporting framework. The end goal of the library is for the user to specify which algorithms they want applied to their data, and then the library produces a document with the results. This document is _not_ meant to be machine readable. As such, I can think of three options: 1) Plain text, with graphs either in seperate image files (using graphviz) or else as plaintext (FGL's show function). 2) Generate LaTeX code. 3) Generate Pandoc [3] compatible Markdown, and let the user convert it into whatever format they prefer. I'm not a big fan of option 1), as it is probably the most unreadable in general. I'd like to use Pandoc, as it is theoretically possible to convert it to numerous other filetypes, however with inline linking there's still no way (at least I can find) to have images scaled to the correct size automatically. So unless I pre-scale the images, using option 3) and then converting to PDF via LaTex generation of the Markdown sources is probably out. As such, what would you all prefer to read as a documentation-style report of your software? 1) A PDF via LaTeX, which has the advantage of being printable and all in one file 2) HTML via Pandoc, which lets you have the images linked separately from the document, and thus no need to shrink them down (they can stay at the natively generated size, and thus easier to zoom in, etc.). Finally, I'll be giving my honours talk on this next Monday. So if you're in Brisbane on 6 October and interested, it'll be on at 2PM at the University of Queensland (where as part of it I'll be explaining to mathematicians why Haskell is a great language to use for mathematics... or at least trying to!). [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Graphalyze [2] http://code.haskell.org/Graphalyze/ [3] http://johnmacfarlane.net/pandoc -- Ivan Lazar Miljenovic [EMAIL PROTECTED] IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: graphviz-2008.9.20
The latest version of Matthew Sackman's Haskell bindings to Graphviz
[1] are now available on Hackage [2]. The reason there's a new
release only two weeks after the previous one is that I've made some
extensions to it (hence why I'm writing the announcement) that Matthew
has kindly included.
Since Matthew doesn't recall writing an announcement for graphviz
before, here is a brief synopsis of what it does. The Graphviz
program is probably _the_ way of drawing graphs (note: this is
graph-theory graphs, not function plotting). As it stands, there are
currently at least four different Haskell bindings available for
Graphviz that I've managed:
* The inbuilt Graphviz module in FGL [3]
* graphviz (which this announcement is for)
* dotgen [4]
* A really simple generator by Duncan Coutts [5]
In addition to this, the following utilities on Hackage output graphs
in Graphviz's .dot format (either using one of the above libraries or
their own parser):
* prof2dot : converts profiling information to .dot [custom, I think] [6]
* flow2Dot : convert textual descriptions to .dot [also custom, I think] [7]
* graphmod : draw the dependencies between Haskell modules [uses dotgen] [8]
As it can be seen, there's a plethora of possible ways of creating
.dot graphs in Haskell. What seperates the graphviz package from the
others is:
* It uses FGL graphs, rather than passing through lists of nodes and
edges manually (of course, if you're not doing any other graph-related
activity you might not want to use an FGL graph), whilst providing
more control than the default FGL module.
* A large list of attributes that can be used are available:
http://hackage.haskell.org/packages/archive/graphviz/2008.9.20/doc/html/Data-GraphViz-Attributes.html
* A "sane" interface that provides a large degree of customizability
(don't specify the attributes manually for each node/edge/etc., just
pass through a function that will create the attribute you want).
* Limited parsing of .dot format (note that as yet it can't convert a
parsed DotGraph into an FGL graph).
* The graphToGraph function allows you to pass a graph through
Graphviz and then extract out positional information and combine it
with the original graph.
There are some things things that graphviz can't do, such as drawing
undirected graphs and clusters (which dotgen can)... at least until
now.
The changes that I have made provide the additional functionality to graphviz:
* Differentiate between undirected and directed graphs. Whilst FGL
represents undirected graphs with a directed graph by duplicating all
edges (an undirected edge {1,2} is represented by the two edges (1,2)
and (2,1)), you don't really want to draw a graph this way.
Furthermore, many reports say that graphviz's "neato" command is
better at drawing undirected graphs than the normal "dot" command is.
Thus, graphviz will now draw only one edge out of every directed pair.
To do so, however, requires that the edge labels are an instance of
Ord: if this is a problem for you, please contact either Matthew or
myself and we'll see what else we can do (this is required because
it's assumed that if two edges (1,2) and (2,1) are meant to represent
the undirected edge {1,2}, then their labels must be the same).
* Add clustering support. Graphs can be drawn (but as yet not parsed)
to provide nested clustering support to arbitrary depth. To do so,
you need to provide a function (LNode a -> NodeCluster c a), where
NodeCluster is the following recursive data type that indicates in
which subcluster a node in the graph belongs:
data NodeCluster c a = N (LNode a) | C c (NodeCluster c a)
The c type represents the cluster label, and is the parameter by which
cluster attributes are assigned. Note that c has to be an instance of
Ord. Clusters are not parseable, because there's no clear way of how
to convert a cluster to an FGL graph.
The interface for graphviz remains unchanged, so you can safely
upgrade to this version.
Here is an example function of how the library can be used to draw an
FGL graph to a (very plain) Graphviz graph (well, it will convert it
to the DotGraph datatype, which when shown produces the .dot graph
code):
graphviz :: (Graph g, Show a, Ord b, Show b) => String -> g a
b -> DotGraph
graphviz title g = graphToDot g attrs nattrs eattrs
where
attrs = [Label title]
nattrs (_,a) = [Label (show a)]
eattrs (_,_,b) = [Label (show b)]
Enjoy!
[1] http://graphviz.org/
[2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/graphviz
[3] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/fgl
[4] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dotgen
[5] http://haskell.org/~duncan/WriteDotGraph.hs
[6] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/prof2dot
[7] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/flow2dot
[8] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/graphmod
--
Ivan Lazar Miljenovic
[EMAIL PROTECTED]
IvanMil
