https://wiki.haskell.org/api.php?action=feedcontributions&user=Psygurd&feedformat=atomHaskellWiki - User contributions [en]2024-03-28T11:34:53ZUser contributionsMediaWiki 1.35.5https://wiki.haskell.org/index.php?title=Talk:How_to_write_a_Haskell_program&diff=8458Talk:How to write a Haskell program2006-11-19T18:57:17Z<p>Psygurd: </p>
<hr />
<div>How do people feel about<br />
<br />
<haskell><br />
#!/usr/bin/env runhaskell<br />
\begin{code}<br />
import Distribution.Simple<br />
main = defaultMain<br />
\end{code}<br />
</haskell><br />
<br />
instead of<br />
<br />
<haskell><br />
#!/usr/bin/env runhaskell<br />
<br />
> import Distribution.Simple<br />
> main = defaultMain<br />
<br />
</haskell><br />
<br />
[[User:DonStewart|dons]] 07:59, 31 October 2006 (UTC)In fact, just this works:<br />
<br />
<haskell><br />
#!/usr/bin/env runhaskell<br />
import Distribution.Simple<br />
main = defaultMain<br />
</haskell><br />
<br />
which is simplest of all<br />
<br />
== Directory structure ==<br />
<br />
Shouldn't the advise be to let all the source code be collected under src/ and the testing under test/ extra scripts under scripts/ etc.?<br />
<br />
== Thanks! ==<br />
<br />
I was putting off (and meaning to get around to) cabalising my software until I saw how easy it was on this page. BTW, I kinda like the birdtracks as is -- kowey 09:20, 31 October 2006 (UTC)</div>Psygurdhttps://wiki.haskell.org/index.php?title=Structure_of_a_Haskell_project&diff=6776Structure of a Haskell project2006-10-08T18:26:32Z<p>Psygurd: The lines where too wide</p>
<hr />
<div>The intention behind this page is to flesh out some semi-standard for<br />
the directory structure, and the tool-setup for medium to large-sized<br />
Haskell projects. It is intended to make it easier for newcomers to<br />
start up projects, and for everybody to navigate others projects.<br />
<br />
Especially I hope some focus can be made on how to make the different<br />
tools play well together, and giving the project structure that allows<br />
scaling.<br />
<br />
Hopefully someone more qualified than I (the initiator of this page)<br />
will be summoned and write their advices, change the faults, add<br />
missing bits and discuss differences in opinions.<br />
<br />
And perhaps a sample project (in the spirit of HNop, but with broader<br />
ambitions) should be made, so that can be used as a template.<br />
<br />
== Tools ==<br />
It is recommended to make use the following tool chain:<br />
* [[Darcs]] for revision control<br />
* [[Cabal]] for managing builds, tests and haddock'ing <br />
* [[QuickCheck]] and [[SmallCheck]] for auto-generated test-cases<br />
* [[HUnit]] for hand-coded tests<br />
* [[Haddock]] for generating API documents<br />
* [[Literate programming]] combined with latex for thorough documentation of the code<br />
<br />
== Directory Structure ==<br />
<br />
For a project called app an outline the directory structure should<br />
look like this (inspired by looking at projects like GHC, PUGS, Yi,<br />
Haskore, Hmp3, Fps):<br />
<br />
<pre><br />
app/ -- Root-dir<br />
src/ -- For keeping the sourcecode<br />
Main.lhs -- The main-module<br />
App/ -- Use hierarchical modules<br />
...<br />
Win32/ -- For system dependent stuff<br />
Unix/<br />
cbits/ -- For C code to be linked to the haskell program<br />
testsuite/ -- Contains the testing stuff<br />
runtests.sh -- Will run all tests<br />
tests/ -- For unit-testing and checking<br />
App/ -- Clone the module hierarchy, so that there is one <br />
testfile per sourcefile<br />
benchmarks/ -- For testing performance<br />
doc/ -- Contains the manual, and other documentation<br />
examples/ -- Example inputs for the program<br />
dev/ -- Information for new developers about the project, <br />
and eg. related litterature<br />
util/ -- Auxiliary scripts for various tasks<br />
dist/ -- Directory containing what end-users should get<br />
build/ -- Contains binary files, created by cabal<br />
doc/ -- The haddock documentation goes here, created by cabal<br />
resources/ -- Images, soundfiles and other non-source stuff<br />
used by the program<br />
_DARCS/ <br />
README -- Textfile with short introduction of the project<br />
INSTALL -- Textfile describing how to build and install<br />
TODO -- Textfile describing things that ought to be done<br />
AUTHORS -- Textfile containing info on who does and has done <br />
what in this project, and their contact info<br />
LICENSE -- Textfile describing licensing terms for this project<br />
app.cabal -- Project-description-file for cabal<br />
Setup.hs -- Program for running cabal commands<br />
</pre><br />
<br />
== Technicalities ==<br />
=== The sourcefiles ===<br />
<br />
* It is recommended to write sourcefiles in plain ascii or UTF-8 with unix line-endings using only spaces (and not tabs) for indentation.<br />
* The interface (everything a module exports) should be commented in english with haddock comments.<br />
* All of the code should be a large latex document going through the code and explaining it. The latex markup should be kept light, so that it is stil readable in an editor. The main module should include all of the files somehow.<br />
* The modules should have explicit export-lists<br />
* Explicit type-annotations should be given for all top-level definitions.<br />
<br />
== Discussions ==<br />
=== Why not use lhs2Tex ===<br />
<br />
Some short experiments showed that lhs2Tex is not too happy about<br />
haddock-comments, and since these two techniques of commenting are<br />
orthogonal something else should be chosen. Eg. [[http://www.acooke.org/jara/pancito/haskell.sty latex.sty]]<br />
<br />
=== How is the testing framework best made? ===<br />
<br />
Here should be a recipe for making a test-framework with both<br />
HUnit-tests an QuickCheck properties, that can all be run with a<br />
simple command, and how to make darcs use that for testing before<br />
recording.</div>Psygurdhttps://wiki.haskell.org/index.php?title=Structure_of_a_Haskell_project&diff=6775Structure of a Haskell project2006-10-08T18:24:56Z<p>Psygurd: Initial page upload</p>
<hr />
<div>The intention behind this page is to flesh out some semi-standard for<br />
the directory structure, and the tool-setup for medium to large-sized<br />
Haskell projects. It is intended to make it easier for newcomers to<br />
start up projects, and for everybody to navigate others projects.<br />
<br />
Especially I hope some focus can be made on how to make the different<br />
tools play well together, and giving the project structure that allows<br />
scaling.<br />
<br />
Hopefully someone more qualified than I (the initiator of this page)<br />
will be summoned and write their advices, change the faults, add<br />
missing bits and discuss differences in opinions.<br />
<br />
And perhaps a sample project (in the spirit of HNop, but with broader<br />
ambitions) should be made, so that can be used as a template.<br />
<br />
== Tools ==<br />
It is recommended to make use the following tool chain:<br />
* [[Darcs]] for revision control<br />
* [[Cabal]] for managing builds, tests and haddock'ing <br />
* [[QuickCheck]] and [[SmallCheck]] for auto-generated test-cases<br />
* [[HUnit]] for hand-coded tests<br />
* [[Haddock]] for generating API documents<br />
* [[Literate programming]] combined with latex for thorough documentation of the code<br />
<br />
== Directory Structure ==<br />
<br />
For a project called app an outline the directory structure should<br />
look like this (inspired by looking at projects like GHC, PUGS, Yi,<br />
Haskore, Hmp3, Fps):<br />
<br />
<pre><br />
app/ -- Root-dir<br />
src/ -- For keeping the sourcecode<br />
Main.lhs -- The main-module<br />
App/ -- Use hierarchical modules<br />
...<br />
Win32/ -- For system dependent stuff<br />
Unix/<br />
cbits/ -- For C code to be linked to the haskell program<br />
testsuite/ -- Contains the testing stuff<br />
runtests.sh -- Will run all tests<br />
tests/ -- For unit-testing and checking<br />
App/ -- Clone the module hierarchy, so that there is one testfile per sourcefile<br />
benchmarks/ -- For testing performance<br />
doc/ -- Contains the manual, and other documentation<br />
examples/ -- Example inputs for the program<br />
dev/ -- Information for new developers about the project, and eg. related litterature<br />
util/ -- Auxiliary scripts for various tasks<br />
dist/ -- Directory containing what end-users should get<br />
build/ -- Contains binary files, created by cabal<br />
doc/ -- The haddock documentation goes here, created by cabal<br />
resources/ -- Images, soundfiles and other non-source stuff used by the program<br />
_DARCS/ <br />
README -- Textfile with short introduction of the project<br />
INSTALL -- Textfile describing how to build and install<br />
TODO -- Textfile describing things that ought to be done<br />
AUTHORS -- Textfile containing info on who does and has done what in this project, and their contact info<br />
LICENSE -- Textfile describing licensing terms for this project<br />
app.cabal -- Project-description-file for cabal<br />
Setup.hs -- Program for running cabal commands<br />
</pre><br />
<br />
== Technicalities ==<br />
=== The sourcefiles ===<br />
<br />
* It is recommended to write sourcefiles in plain ascii or UTF-8 with unix line-endings using only spaces (and not tabs) for indentation.<br />
* The interface (everything a module exports) should be commented in english with haddock comments.<br />
* All of the code should be a large latex document going through the code and explaining it. The latex markup should be kept light, so that it is stil readable in an editor. The main module should include all of the files somehow.<br />
* The modules should have explicit export-lists<br />
* Explicit type-annotations should be given for all top-level definitions.<br />
<br />
== Discussions ==<br />
=== Why not use lhs2Tex ===<br />
<br />
Some short experiments showed that lhs2Tex is not too happy about<br />
haddock-comments, and since these two techniques of commenting are<br />
orthogonal something else should be chosen. Eg. [[http://www.acooke.org/jara/pancito/haskell.sty latex.sty]]<br />
<br />
=== How is the testing framework best made? ===<br />
<br />
Here should be a recipe for making a test-framework with both<br />
HUnit-tests an QuickCheck properties, that can all be run with a<br />
simple command, and how to make darcs use that for testing before<br />
recording.</div>Psygurdhttps://wiki.haskell.org/index.php?title=Talk:Obfuscation&diff=6242Talk:Obfuscation2006-09-23T14:04:51Z<p>Psygurd: dead link</p>
<hr />
<div>Seems like the third link is dead, does anyone know if the page for the Succ Zeroeth competition exists somewhere? [[User:Psygurd|Psygurd]] 14:04, 23 September 2006 (UTC)</div>Psygurdhttps://wiki.haskell.org/index.php?title=Obfuscation&diff=6091Obfuscation2006-09-17T14:23:33Z<p>Psygurd: Corected link to zero'th ohc</p>
<hr />
<div>Haskell is (perhaps surprisingly) an excellent language for code<br />
obfuscation. There have been three Haskell obfuscation contests:<br />
<br />
* [http://www.haskell.org/pipermail/haskell/2004-August/014387.html 1993 Bottomth Obfuscation Haskell Contest]<br />
* [http://iohc.mgoetze.net/ 2003 Zeroth Obfuscated Haskell Contest]<br />
* [http://www.scannedinavian.org/iohcc/succzeroth-2004/ 2004 Succ Zeroth Obfuscated Haskell Contest]<br />
<br />
The ability to use symbols for identifiers helps a lot of course, as<br />
does suspending the use of layout. [[Pointfree]] style is also an<br />
excellent help. Use of strange monads and [[type arithmetic]] can all be<br />
very confusing. Finally, Haskell's clean semantics makes refactoring<br />
code (semi-)mechanical, leading to some interesting obfuscated encodings<br />
(one can replace most Haskell keywords with lambda abstractions, for<br />
example).<br />
<br />
== Example ==<br />
<br />
The following illustrates how, by turning off layout, rewriting keywords<br />
(let, case, where) as lambdas, and using symbols for identifiers (in<br />
this case multiple '?' characters), Haskell may be highly obfuscated.<br />
<br />
--------------------------------------------<br />
module Main where{import List;import System;<br />
import Data.HashTable as H;(???????)=(concat<br />
);(??????)(???)(????)=((groupBy)(???)(????))<br />
;(??????????????????????)(????)=((??????????<br />
)((tail).(???????))((????????????????????)((<br />
??????)(?????????????????????)(????))));(??)<br />
=([' ']);(??????????????)=((hashString));(?)<br />
=((>>=));(???????????????????????)([((???)),<br />
(????)])=((?????????????)(???))?(\(?????)->(<br />
(????????????????)(==)(??????????????))?(\((<br />
???))->((??????????????????)(???????????????<br />
)(???)(?????))>>((?????????????????)(???))?(<br />
\((?????))->((((???????????????????)((????))<br />
((??????????????????????))((?????))))))));((<br />
???????????????????????))(??)=(????????????)<br />
("usage f dic out");(?????????????????????)(<br />
(???),(??????))((????),(????????????????????<br />
))=((???)==(????));(?????????????????)(???)=<br />
(toList)(???);(????????????????????)(????)=(<br />
((??????????)(((??????????)(snd)))((????))))<br />
;(??????????????????)(???????????????)(???)(<br />
(?????))=(((mapM)(((???????????????)(???)))(<br />
(lines)(?????))));(???????????????????)(????<br />
)(???????????????????????)(?????)=(?????????<br />
)(????)((unlines)((???????????????????????)(<br />
?????)));(????????????????)(???)((????))=(((<br />
new)(???)(????)));(main)=((???????????)?(((\<br />
(???)->((???????????????????????)(???))))));<br />
(???????????????)(???)(????)=((????????)(???<br />
)((sort)(????))((??)++(????)));(???????????)<br />
=(getArgs);(????????????)(???)=((((print))((<br />
???))));(??????????)(???)(????)=(((map)(???)<br />
(????)));(????????)((???))(????)(?????)=((((<br />
H.insert))((???))(????)(?????)));(?????????)<br />
((???))((????))=(((writeFile)(???)((????))))<br />
;(?????????????)(???)=(((readFile)((???))))}<br />
--------------------------------------------<br />
<br />
[[Category:Idioms]]</div>Psygurd