Re: [Haskell-cafe] lhs2TeX: automatic line wrap within code blocks?
David,
The easiest solution is probably to use multi-line string literals and
line-wrap manually:
\begin{code}
cyphertext = rlkmlj, zlnift ekblvke pqc elvm if pzlp gblrk, akrlomk zk zle \
lfpiriglpke pzlp, if pzk flpojlb rcojmk cs knkfpm, morz qcobe ak pzk rcfeorp \
cs nkjriftkpcjiu, bklnkm pzk ljdv ofekj gjkpkfmk cs jlimift jkrjoipm lfe \
rlnlbjv
\end{code}
Dominique
Op 4 april 2012 20:14 heeft david.mihola david.mih...@gmail.com het
volgende geschreven:
Hello,
I am currently using lhs2TeX for the first time and have encountered a
problem which I am unable to solve myself: Some code lines are too long to
fit into a single line of the output (PDF) file and thus go off the right
edge of the page.
Consider the following example:
-
\documentclass{article}
\usepackage[utf8]{inputenc}
%include polycode.fmt
%options ghci
\begin{document}
Our encrypted message:
\begin{code}
cyphertext = rlkmlj, zlnift ekblvke pqc elvm if pzlp gblrk, akrlomk zk zle
lfpiriglpke pzlp, if pzk flpojlb rcojmk cs knkfpm, morz qcobe ak pzk rcfeorp
cs nkjriftkpcjiu, bklnkm pzk ljdv ofekj gjkpkfmk cs jlimift jkrjoipm lfe
rlnlbjv
\end{code}
Our decryption function:
\begin{code}
decrypt = id
\end{code}
The original message was:
\eval{decrypt cyphertext}
\end{document}
-
Converting this to .tex with lhs2TeX and to .pdf with pdflatex produces a
PDF in which both instances of the cyphertext go off the right edge of the
page.
Is there any way to tell lhs2TeX to allow/force line wrap within code blocks
and eval-statements?
Thank you very much for any help!
David
P.S.: I have only found one prior discussion of my question
(http://tex.stackexchange.com/questions/15048/how-to-typeset-a-multiline-text-in-math-environment)
but to my understanding no real answer came out of that.
--
View this message in context:
http://haskell.1045720.n5.nabble.com/lhs2TeX-automatic-line-wrap-within-code-blocks-tp5618600p5618600.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] lhs2TeX: automatic line wrap within code blocks?
Dominique,
thank you very much for your reply!
Yes, that would work for the code-blocks, but I'd still prefer
automatic line wrapping like in this example:
http://www.bollchen.de/blog/2011/04/good-looking-line-breaks-with-the-listings-package/
Also this does not solve the case of multi line results in eval-statements.
But still, thanks again - and as my deadline draws nearer (this is
homework in a security lecture) I may use your solution and also
decrypt the text first and then copy the decrypted text into the
source file (to get rid of the eval-statement).
David
Am 5. April 2012 08:01 schrieb Dominique Devriese
dominique.devri...@cs.kuleuven.be:
David,
The easiest solution is probably to use multi-line string literals and
line-wrap manually:
\begin{code}
cyphertext = rlkmlj, zlnift ekblvke pqc elvm if pzlp gblrk, akrlomk zk zle \
lfpiriglpke pzlp, if pzk flpojlb rcojmk cs knkfpm, morz qcobe ak pzk rcfeorp
\
cs nkjriftkpcjiu, bklnkm pzk ljdv ofekj gjkpkfmk cs jlimift jkrjoipm lfe \
rlnlbjv
\end{code}
Dominique
Op 4 april 2012 20:14 heeft david.mihola david.mih...@gmail.com het
volgende geschreven:
Hello,
I am currently using lhs2TeX for the first time and have encountered a
problem which I am unable to solve myself: Some code lines are too long to
fit into a single line of the output (PDF) file and thus go off the right
edge of the page.
Consider the following example:
-
\documentclass{article}
\usepackage[utf8]{inputenc}
%include polycode.fmt
%options ghci
\begin{document}
Our encrypted message:
\begin{code}
cyphertext = rlkmlj, zlnift ekblvke pqc elvm if pzlp gblrk, akrlomk zk zle
lfpiriglpke pzlp, if pzk flpojlb rcojmk cs knkfpm, morz qcobe ak pzk rcfeorp
cs nkjriftkpcjiu, bklnkm pzk ljdv ofekj gjkpkfmk cs jlimift jkrjoipm lfe
rlnlbjv
\end{code}
Our decryption function:
\begin{code}
decrypt = id
\end{code}
The original message was:
\eval{decrypt cyphertext}
\end{document}
-
Converting this to .tex with lhs2TeX and to .pdf with pdflatex produces a
PDF in which both instances of the cyphertext go off the right edge of the
page.
Is there any way to tell lhs2TeX to allow/force line wrap within code blocks
and eval-statements?
Thank you very much for any help!
David
P.S.: I have only found one prior discussion of my question
(http://tex.stackexchange.com/questions/15048/how-to-typeset-a-multiline-text-in-math-environment)
but to my understanding no real answer came out of that.
--
View this message in context:
http://haskell.1045720.n5.nabble.com/lhs2TeX-automatic-line-wrap-within-code-blocks-tp5618600p5618600.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Yesod 1.0 Release Candidate
Hi everyone, I'd like to announce the availability of the Yesod 1.0 release candidate. The code is available on Hackage now, so you should be able to install with a simple `cabal update cabal install yesod` to get up-and-running. If you've been installing from Github or Yackage, you'll probably have the smoothest ride by wiping out your ~/.ghc and ~/.cabal/packages/cabal-src folders, and disabling Yackage as a remote repo in ~/.cabal/config. We're setting a release date of next Monday, April 9. That's when we'll be posting an official release announcement and releasing a new version of yesod-platform. At this point, the code is well tested and usable (in fact, it *is* in production use on multiple sites), but we wanted to give everyone one last chance to hammer away at the code. One of the goals with this release is to try to start pushing Haskell and Yesod to the masses (i.e., we're going to fail to avoid success at all costs). We're going to be trying to demonstrate the advantages Haskell provides over other solutions out there. I think this is the kind of effort that we can all work on together as a community. If anyone's interested in helping out with promoting, please be in touch. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell integration with C/C++ (GSOC)
I love the idea of easier to use FFI, but isn't the haskell FFI
intentionally very low level, and intended to be used with tools?
In that light, maybe it would be easier to extend hsc2hs with fancier
macros and the ability to generate wrappers to directly call C++
methods and construct C++ objects. E.g. you could write
obj - #new Thing, arg, arg
and it would generate
extern C newThing(int arg, int arg) { return new Thing(arg, arg); }
I guess then you need it to be able to automatically insert 'foreign'
declarations, and convert between types, and at that point you're
already halfway to something like SWIG or green card. Or c2hs, not
that I know anything about that. Anyway, maybe you can add C++
support to an existing preprocessor instead of putting it directly
into ghc.
One reason I like hsc2hs is the control it gives me. That said, I
have a lot of pretty standard boilerplate Storable instances,
withCString, etc. And a file of trivial extern C wrappers to bridge
from C++. There's a lot of room for automation in there.
On Wed, Apr 4, 2012 at 10:53 PM, Sutherland, Julian
julian.sutherlan...@imperial.ac.uk wrote:
Hey Guys,
I'm Julian, I am reaching the end of my second year as a JMC (Joint
Mathematics and Computer science) Student at Imperial College London
and I'd like to apply to GSOC for a project involving Haskell and I just
wanted to run my idea past the community.
I've already talked about this on the haskell-soc IRC channel (I go by the
pseudonym julek).
What I would like to do is to improve the integration of C/C++ with Haskell,
particularly in calling Haskell from C/C++.
Currently ghc is able to generate stubs to export functions whose arguments
are simple types such as CInts into C/C++.
The stub generated is always in an extern C clause due to the fact that
ghc does not as yet implement the C++
calling conventions as defined in the The Haskell 98 Foreign Function
Interface 1.0 (http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi.pdf)
So a first step would be to implement this calling convention to bring it up
to speed with the above referenced report.
This shouldn't be too hard and mostly involves implementing C++ name
mangling conventions.
Next, I would like to extend the stub generation so as to be able to deal
with more complex types.
The type systems in C++ and Haskell have many analogous syntaxes that can be
easily exploited to provide strong compatibility and interoperability
between the two languages.
For example a simple type such as:
data Foo = A | B
Could be implemented as an enum in C/C++:
enum Foo {A, B};
More advanced types that take arguments such as:
data Tree = Node Left Right | Leaf
Could be converted to a struct in C/C++:
struct Tree {
struct Tree* left;
struct Tree* right;
};
Types that have functions that act on them such as:
data IntContainer = IntContainer Int
getInt :: IntContainer - Int
getInt (IntContainer a) = a
could have these functions automatically converted to C/C++:
struct IntContainer {
int a;
};
extern int getInt_hs(IntContainer a);
This also opens up the possibility of exploiting C/C++ name mangling
conventions, to allow the _hs postfix I'm suggesting here to be eliminated.
Haskell classes:
class Arithmetic a where
(+) :: a - a - a
(*) :: a - a - a
(-) :: a - a - a
(/) :: a - a - a
could be implemented using C++ functions with virtual members:
class Monad {
public:
virtual Monad add(Monad a, Monad b);
virtual Monad mult(Monad a, Monad b)
virtual Monad neg(Monad a, Monad b);
virtual Monad div(Monad a, Monad b);
}
All types of single/multiple instancing (i.e. either directly or through
requirements of instances)
would be implemented using single/multiple inheritance.
Obviously, this example is rather contrived due to the conversion of the
function names.
The fact that the rules that govern function naming in Haskell are much more
permissive
than those of C/C++ might cause compatibility issues.
This can be worked around by implementing a similar syntax to that currently
used for function imports by the FFI.
E.g..:
foreign export ccall bind = :: CInt - CInt
Similar to:
foreign import ccall f func :: CInt - CInt
The latter is the current syntax for imports.
The name given for the export would be checked for legality in the namespace
of the target language.
Alternatively this could be done in an automated manner using some naming
conventions as well as operator polymorphism, but this would probably
sacrifice ease of use.
Finally polymorphic Haskell functions/types can be implemented in C++ using
templates.
I would like to extend ghc to implement enhanced C/C++ stub generation using
the methods described above as well as to generate Haskell stubs which
describe the Haskell CType equivalents of the Haskell types defined,
functions for conversion between the two and function
Re: [Haskell-cafe] Haskell integration with C/C++ (GSOC)
On Thu, Apr 5, 2012 at 01:53, Sutherland, Julian
julian.sutherlan...@imperial.ac.uk wrote:
data Tree = Node Left Right | Leaf
Could be converted to a struct in C/C++:
struct Tree {
struct Tree* left;
struct Tree* right;
};
Shouldn't this actually be a tagged union? Not that they exist as such in
C/C++, but are easy enough to emulate (minus the extra type checking that
real tagged unions such as even Pascal gives you):
struct Tree {
enum {Node, Leaf} tag;
/* possibly tag sanity checking macros defined here */
union {
struct {
struct Tree *tree_Node_left;
#ifdef HSC_CHECKED
# define tree_left(tree) (tree-tag == Leaf ? _hsc_abort(tree:
Node.left of Leaf) : tree-_tree_Node.tree_Node_left)
#else
# define tree_left(tree) tree-_tree_Node.tree_Node_left
#endif
struct Tree *tree_Node_right;
#ifdef HSC_CHECKED
# define tree_right(tree) (tree-tag == Leaf ? _hsc_abort(tree:
Node.right of Leaf) : tree-_tree_Node.tree_Node_right)
#else
# define tree_right(tree) tree-_tree_Node.tree_Node_right
#endif
} _tree_Node;
/* strictly we can collapse out the union here because Leaf has no
data */
} _tree_data;
Similarly several of your other examples could use a bit more thought.
--
brandon s allbery allber...@gmail.com
wandering unix systems administrator (available) (412) 475-9364 vm/sms
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fail-back monad
I thoutgh on the use or ErrorT or something similar but the fact is
that i need many bacPoints, not just one. That is, The user can go
many pages back in the navigation pressing many times te back
buttton.
The approach in the previous message extends to an arbitrary,
statically unknown number of checkpoints. If we run the following
simple code
test1 = loop 1
where
loop acc n = inquire (Enter string ++ show n) = check acc n
check acc n = liftIO . putStrLn $ You have entered: ++ acc
check acc n str = loop (acc ++ str) (n+1)
test1r = runContT test1 return
we can do the following:
*BackT test1r
Enter string 1
s1
Enter string 2
s2
Enter string 3
s3
Enter string 4
s4
Enter string 5
back
Enter string 4
back
Enter string 3
back
Enter string 2
x1
Enter string 3
x2
Enter string 4
x3
Enter string 5
back
Enter string 4
y3
Enter string 5
You have entered: s1x1x2y3
I decided to go back after the fourth string, but you should feel free
to go forth.
The ContT approach is very flexible: we can not only go back, or go
back more. We can go all the way back. We can go back to the point
where certain condition was true, like when the value of the certain
named field was entered or certain value was computed.
Here is the complete code. For a change, it uses IO exceptions rather
than ErrorT.
{-# LANGUAGE DeriveDataTypeable #-}
module BackT where
import Control.Monad.Trans
import Control.Monad.Cont
import Control.Exception
import Data.Typeable
import Prelude hiding (catch)
data RestartMe = RestartMe deriving (Show, Typeable)
instance Exception RestartMe
-- Make a `restartable' exception
-- (restartable from the beginning, that is)
-- We redo the computation once we catch the exception RestartMe
-- Other exceptions propagate up as usual.
type BackT r m a = ContT r m a
abort e = ContT(\k - e)
-- Send a prompt, receive a reply. If it is back, go to the
-- previous checkpoint.
type Prompt = String
inquire :: Prompt - BackT r IO String
inquire prompt = ContT loop
where
loop k = exchange = checkpoint k
exchange = do
putStrLn prompt
r - getLine
if r == back then throw RestartMe
else return r
checkpoint k r = k r `catch` (\RestartMe - loop k)
-- Go to the previous checkpoint
goBack :: BackT r m a
goBack = abort (throw RestartMe)
test1 = loop 1
where
loop acc n = inquire (Enter string ++ show n) = check acc n
check acc n = liftIO . putStrLn $ You have entered: ++ acc
check acc n str = loop (acc ++ str) (n+1)
test1r = runContT test1 return
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell integration with C/C++ (GSOC)
Am 05.04.2012 um 08:42 schrieb Brandon Allbery:
On Thu, Apr 5, 2012 at 01:53, Sutherland, Julian
julian.sutherlan...@imperial.ac.uk wrote:
data Tree = Node Left Right | Leaf
Could be converted to a struct in C/C++:
struct Tree {
struct Tree* left;
struct Tree* right;
};
Shouldn't this actually be a tagged union? Not that they exist as such in
C/C++, but are easy enough to emulate (minus the extra type checking that
real tagged unions such as even Pascal gives you):
Not necessarily. The above type is equivalent to
type Tree = Maybe (Left, Right)
(modulo strictness, of course) and the C/C++ convention is to represent Nothing
by a NULL pointer.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell integration with C/C++ (GSOC)
On Thu, Apr 5, 2012 at 03:21, Holger Siegel holgersiege...@yahoo.de wrote:
Am 05.04.2012 um 08:42 schrieb Brandon Allbery:
On Thu, Apr 5, 2012 at 01:53, Sutherland, Julian
julian.sutherlan...@imperial.ac.uk wrote:
data Tree = Node Left Right | Leaf
Could be converted to a struct in C/C++:
struct Tree {
struct Tree* left;
struct Tree* right;
};
Shouldn't this actually be a tagged union? Not that they exist as such
in C/C++, but are easy enough to emulate (minus the extra type checking
that real tagged unions such as even Pascal gives you):
Not necessarily. The above type is equivalent to
type Tree = Maybe (Left, Right)
But that is not the type being translated. (Also, I would still consider
translating Maybe as something other than a NULL pointer, just to enable
sanity checking.)
--
brandon s allbery allber...@gmail.com
wandering unix systems administrator (available) (412) 475-9364 vm/sms
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fail-back monad
There is also recent work by Aaron Turon and Olin Shivers - Modular Rollback through Control Logging http://www.ccs.neu.edu/home/shivers/ http://www.ccs.neu.edu/home/turon/ Note that as well as the paper on Olin Shivers's site there is a more recent monadic presentation on Aaron Turon's site with Conor McBride... On 28 March 2012 18:11, Stephen Tetley stephen.tet...@gmail.com wrote: Maybe this is a version of William Harrison's DebugT monad with rollback, listed in his periodic table of effects? http://www.cs.missouri.edu/~harrisonwl/Presentations/UIUCFM05.ppt I've never seen a definition of the monad itself... http://www.haskell.org/pipermail/beginners/2010-January/003371.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] thread killed
+haskell-cafe, oops On Thu, Apr 5, 2012 at 11:04 AM, Gregory Collins g...@gregorycollins.netwrote: On Wed, Apr 4, 2012 at 10:09 PM, tsuraan tsur...@gmail.com wrote: It's hard to rule Snap timeouts out; try building snap-core with the -fdebug flag and running your app with DEBUG=1, you'll get a spew of debugging output from Snap on stderr. Heh, that was quite a spew. I normally get the exceptions tens of MB into files that are hundreds of MB, and I sometimes don't get them at all, so printing out the entire request body was a bit slow :) After commenting out some of the more talkative debug statements, I got the exception to happen, and it looks generally like this: I think I might know what your problem is. You're accepting file uploads using handleMultipart, yes? Snap kills uploads that are going too slow, otherwise you would be vulnerable to slowloris ( http://ha.ckers.org/slowloris/) DoS attacks. What's probably happening here is that you're doing slow work inside the Iteratee IO a handler you pass to that function, which makes Snap think the client is trickling bytes to you. If that's the case, either finish the iteratee more quickly and do the slow work back in the Snap handler (preferable), or disable the minimum upload rate guard (although that's not recommended on a server talking to the public internet.) G -- Gregory Collins g...@gregorycollins.net -- Gregory Collins g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] thread killed
On Thu, Apr 5, 2012 at 12:05 PM, Gregory Collins g...@gregorycollins.net wrote: +haskell-cafe, oops On Thu, Apr 5, 2012 at 11:04 AM, Gregory Collins g...@gregorycollins.net wrote: On Wed, Apr 4, 2012 at 10:09 PM, tsuraan tsur...@gmail.com wrote: It's hard to rule Snap timeouts out; try building snap-core with the -fdebug flag and running your app with DEBUG=1, you'll get a spew of debugging output from Snap on stderr. Heh, that was quite a spew. I normally get the exceptions tens of MB into files that are hundreds of MB, and I sometimes don't get them at all, so printing out the entire request body was a bit slow :) After commenting out some of the more talkative debug statements, I got the exception to happen, and it looks generally like this: I think I might know what your problem is. You're accepting file uploads using handleMultipart, yes? Snap kills uploads that are going too slow, otherwise you would be vulnerable to slowloris (http://ha.ckers.org/slowloris/) DoS attacks. What's probably happening here is that you're doing slow work inside the Iteratee IO a handler you pass to that function, which makes Snap think the client is trickling bytes to you. If that's the case, either finish the iteratee more quickly and do the slow work back in the Snap handler (preferable), or disable the minimum upload rate guard (although that's not recommended on a server talking to the public internet.) Wouldn't it make more sense to pause the timeout handler when running user code? That's what we do in Warp. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell integration with C/C++ (GSOC)
On Thursday, April 5, 2012 at 1:53 AM, Sutherland, Julian wrote:
Hey Guys,
I'm Julian, I am reaching the end of my second year as a JMC (Joint
Mathematics and Computer science) Student at Imperial College London
and I'd like to apply to GSOC for a project involving Haskell and I just
wanted to run my idea past the community.
[snip]
I found an example of such a bug, which I will test further before reporting
it.
It seems to be the opposite of the following bug:
http://hackage.haskell.org/trac/ghc/ticket/5594
i.e. the stdout buffer isn't always correctly flushed when calling C/C++ in a
program whose main is written in Haskell.
For example, when running the code:
main.hs:
module Main where
import Foreign.C.Types
import System.IO
foreign import ccall inc c_inc :: CInt - CInt
main :: IO ()
main = do
putStr Enter n:
-- hFlush stdout
s -getLine
putStrLn . show . c_inc . read $ s
inc.c:
int inc(int i) __attribute__ ((const));
int inc(int i)
{
return i + 1;
}
Built with
Makefile:
all:
gcc -c -o inc.o inc.c
ghc --make -main-is Main main.hs inc.o -o test
rm *.hi *.o
The output comes out as:
[julek@cryptid inc]$ ./test
2
Enter n: 3
But when the hFlush stdout line is commented back in, the output is:
[julek@cryptid inc]$ ./test
Enter n: 2
3
which is correct, but the extra line shouldn't be necessary.
I am currently using ghc 7.4.1 which is the newest version, so this is a
current bug.
I think this is a consequence of line buffering rather than a bug. If you write
your own increment function in Haskell, you get the same behavior. If you
`hSetBuffering stdout NoBuffering` before your `putStr` call, you should get
the behavior you wanted. I've seen similar issues with programs written in many
languages; it's just one of those gotchas to be aware of when dealing with
console UI.
As to the rest of your proposal, when you started out talking about calling
Haskell from C or C++, I hoped you would focus on the pain of linking the final
executable. This seems to me a more fundamental -- and addressable -- stumbling
block than the richness of interaction with C++. As things stand, it is quite a
hassle to use a Haskell library of any complexity called from C. Improved
interaction with C++ could indeed be valuable, but, unless something has
changed recently, work is still needed to improve the more basic C - Haskell
FFI story.
Anthony
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] I Need a Better Functional Language!
Hello! I've just realized that Haskell is no good for working with functions! First, what are 'functions' we are interested at? It can't be the usual set-theoretic definition, since it is not constructive. The constructive definition should imply functions that can be constructed, computed. Thus these are computable functions that should be of our concern. But computable functions in essence are just a synonym for programs. One could expect from a language that bears 'functional' as its characteristic to be able to do everything imaginable with functions. However, the only thing Haskell can do with functions is to apply them to arguments and to feed them as arguments, run in parallel (run and concatenate programs). Obviously, that's not all of the imaginable possibilities. One also can rewrite programs. And write programs that rewrite programs. And write programs that rewrite programs that rewrite the first programs and so on. But there is no such possibility in Haskell, except for introducing a DSL. So now I wonder, what are the languages that are functional in the sense above? With a reasonable syntax and semantics, thus no assembler. I guess Lisp might be of this kind, but I'm not sure. In addition, I'm not a fan of parentheses. What else? Pure? Mathematica? Maxima? Note, that the reflectivity is important. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I Need a Better Functional Language!
Le 5 avril 2012 16:14, Grigory Sarnitskiy sargrig...@ya.ru a écrit : Hello! I've just realized that Haskell is no good for working with functions! First, what are 'functions' we are interested at? It can't be the usual set-theoretic definition, since it is not constructive. The constructive definition should imply functions that can be constructed, computed. Thus these are computable functions that should be of our concern. But computable functions in essence are just a synonym for programs. One could expect from a language that bears 'functional' as its characteristic to be able to do everything imaginable with functions. However, the only thing Haskell can do with functions is to apply them to arguments and to feed them as arguments, run in parallel (run and concatenate programs). Obviously, that's not all of the imaginable possibilities. One also can rewrite programs. And write programs that rewrite programs. And write programs that rewrite programs that rewrite the first programs and so on. But there is no such possibility in Haskell, except for introducing a DSL. So now I wonder, what are the languages that are functional in the sense above? With a reasonable syntax and semantics, thus no assembler. I guess Lisp might be of this kind, but I'm not sure. In addition, I'm not a fan of parentheses. What else? Pure? Mathematica? Maxima? Hello, You might be interested in https://github.com/MikeHaskel/Constructiva/wiki Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is this a correct explanation of FRP?
On Thu, Apr 5, 2012 at 4:30 AM, Ertugrul Söylemez e...@ertes.de wrote: Paul Liu nine...@gmail.com wrote: This isn't switching. It's selection. If fullTime decides to be productive, then alterTime acts like fullTime. Otherwise it acts like halfTime. If both inhibit, then alterTime inhibits. This allows for a much more algebraic description of reactive systems. AFRP can do this through ArrowChoice. Maybe you can explain the concept of inhibition in more detail? I fail to grasp why this is making switches obsolete. The idea of switch is to completely abandoning the old state. See the broken pendulum example. Some of this can be done through ArrowChoice. The difference is comparable to why server parts form a monoid in Happstack. You don't have to decide when a server part reaches a request. You let the server part decide itself. In other words ArrowChoice forces you to deal with events in the application itself: -- Library code: x = x' y = y' -- Application code: proc inp - do r - request - () if p r then x - inp else y - inp Signal inhibition allows the component wires themselves to deal with the events and you as the higher level programmer to just stick the wires together: -- Library code: x = proc inp - do requireReq - (); x' - inp y = y' -- Application code: x | y I'm curious as to how this plays out with the usual arrow compositions. How does x *** y behave when x inhibits? what about z x? This cannot replace switching though, since the structure of your arrows cannot change dynamically, while with switches it can. -- Regards, Paul Liu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell integration with C/C++ (GSOC)
Quoth Anthony Cowley acow...@seas.upenn.edu, ... I think this is a consequence of line buffering rather than a bug. If you write your own increment function in Haskell, you get the same behavior. If you `hSetBuffering stdout NoBuffering` before your `putStr` call, you should get the behavior you wanted. Though if you must do one or the other, I think hFlush makes as much sense. I think his perspective may be that the C stdio library appears to recognize that a TTY read is an occasion to flush stdout. If you already know better, there are ways to solve this problem - flush, change buffering, or use stderr instead of stdout. If you weren't expecting it, though, Haskell might by comparison seem a little retarded. Maybe it isn't a bug. As things stand, it is quite a hassle to use a Haskell library of any complexity called from C. And Haskell is slightly handicapped in this application, if it still doesn't support any good mechanism for top level mutable state (Cf. http://www.haskell.org/haskellwiki/Top_level_mutable_state ) I wonder if the fact that we recognize these problems but haven't been super-motivated to solve them, suggests that there hasn't really been that much call for stand alone Haskell libraries? (The proposal seems to say that C++ programmers could jump at this opportunity because they've been wanting to use Haskell but were afraid of the IO Monad?) Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I Need a Better Functional Language!
On 5 Apr 2012, at 15:14, Grigory Sarnitskiy wrote: Hello! I've just realized that Haskell is no good for working with functions! Obviously, that's not all of the imaginable possibilities. One also can rewrite programs. And write programs that rewrite programs. And write programs that rewrite programs that rewrite the first programs and so on. But there is no such possibility in Haskell, except for introducing a DSL. So now I wonder, what are the languages that are functional in the sense above? With a reasonable syntax and semantics, thus no assembler. I guess Lisp might be of this kind, but I'm not sure. Probably - but the semantics is dreadful... Note, that the reflectivity is important. Intel developed a reflective functional language/system called Forte that is the basic of a lot of their formal hardware verification process... http://www.cs.ox.ac.uk/tom.melham/res/forte.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Lero@TCD, Head of Foundations Methods Research Group Director of Teaching and Learning - Undergraduate, School of Computer Science and Statistics, Room G.39, O'Reilly Institute, Trinity College, University of Dublin http://www.scss.tcd.ie/Andrew.Butterfield/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I Need a Better Functional Language!
Addendum: Intel's Forte was the framework, reFLect was the language : http://www.cs.ox.ac.uk/tom.melham/res/reflect.html Quoting that page: reFLect is a functional programming language designed and implemented by a team at Intel Corporation's Strategic CAD Labs under the direction of Jim Grundy. The language is strongly typed and similar to ML, but provides certain reflection features intended for applications in industrial hardware design and verification. Like LISP, reFLect has quotation and antiquotation constructs that may be used to construct and decompose expressions in the language itself. Unlike LISP, these mechanisms are typed. The language also provides a primitive mechanism for pattern-matching, and in particular for defining functions over code by pattern-matching on the structure of reFLect expressions. On 5 Apr 2012, at 15:14, Grigory Sarnitskiy wrote: Hello! I've just realized that Haskell is no good for working with functions! First, what are 'functions' we are interested at? It can't be the usual set-theoretic definition, since it is not constructive. The constructive definition should imply functions that can be constructed, computed. Thus these are computable functions that should be of our concern. But computable functions in essence are just a synonym for programs. One could expect from a language that bears 'functional' as its characteristic to be able to do everything imaginable with functions. However, the only thing Haskell can do with functions is to apply them to arguments and to feed them as arguments, run in parallel (run and concatenate programs). Obviously, that's not all of the imaginable possibilities. One also can rewrite programs. And write programs that rewrite programs. And write programs that rewrite programs that rewrite the first programs and so on. But there is no such possibility in Haskell, except for introducing a DSL. So now I wonder, what are the languages that are functional in the sense above? With a reasonable syntax and semantics, thus no assembler. I guess Lisp might be of this kind, but I'm not sure. In addition, I'm not a fan of parentheses. What else? Pure? Mathematica? Maxima? Note, that the reflectivity is important. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Lero@TCD, Head of Foundations Methods Research Group Director of Teaching and Learning - Undergraduate, School of Computer Science and Statistics, Room G.39, O'Reilly Institute, Trinity College, University of Dublin http://www.scss.tcd.ie/Andrew.Butterfield/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I Need a Better Functional Language!
On Thu, Apr 5, 2012 at 10:14 AM, Grigory Sarnitskiy sargrig...@ya.ru wrote: First, what are 'functions' we are interested at? It can't be the usual set-theoretic definition, since it is not constructive. The constructive definition should imply functions that can be constructed, computed. Thus these are computable functions that should be of our concern. But computable functions in essence are just a synonym for programs. This is a flawed premise. The point of working with functions is abstraction, and that abstraction is given by extensional equality of functions: f = g iff forall x. f x = g x So functions are not synonymous with programs or algorithms, they correspond to an equivalence class of algorithms that produce the same results from the same starting points. If you can access the source of functions within the language, this abstraction has been broken. And this abstraction is useful, because it allows you to switch freely between programs that do the same thing without having to worry that someone somewhere is relying on the particular algorithm or source. This is the heart of optimization and refactoring and the like. There are places for metaprogramming, or perhaps even a type of algorithms that can be distinguished by means other than the functions they compute. But to say that functions are that type is false, and that functions should mean that is, I think, wrong headed. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I Need a Better Functional Language!
Grigory So now I wonder, what are the languages that are functional in Grigory the sense above? With a reasonable syntax and semantics, thus Grigory no assembler. I guess Lisp might be of this kind, but I'm not Grigory sure. In addition, I'm not a fan of parentheses. What else? Grigory Pure? Mathematica? Maxima? Indeed you want a *different* programming language. But it won't be *better*, just different. Indeed, as soon as your program react to the implementation of its functions, you will be in a land where you lose a fundamental abstraction, so you won't be able to change implementation anymore whithout changing callers as well. I am curious what are interesting use-cases for that ? Symbolic analysis ? self-compilers ? -- Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] thread killed
I think I might know what your problem is. You're accepting file uploads using handleMultipart, yes? Snap kills uploads that are going too slow, otherwise you would be vulnerable to slowloris (http://ha.ckers.org/slowloris/) DoS attacks. What's probably happening here is that you're doing slow work inside the Iteratee IO a handler you pass to that function, which makes Snap think the client is trickling bytes to you. If that's the case, either finish the iteratee more quickly and do the slow work back in the Snap handler (preferable), or disable the minimum upload rate guard (although that's not recommended on a server talking to the public internet.) I tried adding a setMinimumUploadRate 0 to my handleMultipart and doing the upload, and it's still getting killed. The uploads are pretty fast; a 150MB file takes around 10s. I really don't think the problem is with Snap, but pulling my code out of snap would be pretty painful. I have some pretty nasty crap going on with what I'm doing anyhow, with threads communicating asynchronously, sockets being held open between requests, that sort of horrid ugliness. I'm going to try to get rid of that, and then see if any bugs I had in there were causing the problem. Hopefully I'll be done with that by the end of the weekend, and I'll either have the problem fixed, or have a reasonable way to reproduce the errors. Thanks for the idea, anyhow. And, if setMinimumUploadRate 0 doesn't actually disable the rate limiter, I'd be happy to try something more correct. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] thread killed
I think I might know what your problem is. You're accepting file uploads using handleMultipart, yes? Snap kills uploads that are going too slow, otherwise you would be vulnerable to slowloris (http://ha.ckers.org/slowloris/) DoS attacks. What's probably happening here is that you're doing slow work inside the Iteratee IO a handler you pass to that function, which makes Snap think the client is trickling bytes to you. If that's the case, either finish the iteratee more quickly and do the slow work back in the Snap handler (preferable), or disable the minimum upload rate guard (although that's not recommended on a server talking to the public internet.) Ok, so I butchered Snap by replacing all of snap-server's killThread calls with putStrLn calls, and the putStrLn that is triggered by Snap.Internal.Http.Server.SimpleBackend's runSession (line 163 in snap-server 0.8.0.1) seems to be the culprit. Is that a rate limiter, or is that something else? Anyhow, I think there's a bug in there somewhere. I'll be poking at it a bit more, but that seems to be the top-level source of the errors. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Google Summer of Code - Lock-free data structures
perhaps it is too late to suggest things for GSOC -- but stephen tetley on a different thread pointed at aaron turon's work, which there's a very interesting new concurrency framework he calls reagents which seems to give the best of all worlds : it is declarative and compositional like STM, but gives performance akin to hand-coded lock-free data structures. he seems to have straddled the duality of isolation vs message-passing nicely, and can subsume things like actors and the join calculus. http://www.ccs.neu.edu/home/turon/reagents.pdf he has a BSD licensed library in scala at https://github.com/aturon/ChemistrySet if someone doesn't want to pick this up for GSOC i might have a hand at implementing it myself. b On Mar 29, 2012, at 6:46 AM, Tim Harris (RESEARCH) wrote: Hi, Somewhat related to this... Next month we have a paper coming up at EuroSys about a middle-ground between using STM and programming directly with CAS: http://research.microsoft.com/en-us/um/people/tharris/papers/2012-eurosys.pdf This was done in the context of shared memory data structures in C/C++, rather than Haskell. It might be interesting to see how the results carry over to Haskell, e.g. adding short forms of specialized transactions that interact correctly with normal STM-Haskell transactions. In the paper we have some examples of using short specialized transactions for the fast paths in data structures, while keeping the full STM available as a fall-back for expressing the cases that cannot be implemented using short transactions. --Tim -Original Message- From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Heinrich Apfelmus Sent: 29 March 2012 13:30 To: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Google Summer of Code - Lock-free data structures Florian Hartwig wrote: Heinrich Apfelmus wrote: So while the two are related, CAS is a machine primitive that works for a single operation and on a single word while STM is a software abstraction that isolates sequences of operations on multiple memory locations from each other. Is it possible to implement every data structure based on CAS in terms of STM? What are the drawbacks? The other way round? I think so. Atomically reading and writing a single memory location (which CAS does) is just a very simple transaction. But using a CAS instruction should be more efficient, since STM has to maintain a transaction log and commit transactions, which creates some overhead. Ah, I see. In that case, it may be worthwhile to implement the CAS instruction in terms of STM as well and measure the performance difference this makes for the final data structure. After all, STM is a lot more compositional than CAS, so I'd like to know whether the loss of expressiveness is worth the gain in performance. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I Need a Better Functional Language!
Paul R wrote: I am curious what are interesting use-cases for that? Symbolic analysis? self-compilers? Optimization. For example, imagine the following definition of function composition: map f . map g = map (f . g) f . g = \x - f (g x) In Haskell, we cannot write this, because we cannot pattern match on function calls. Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Google Summer of Code - Lock-free data structures
Ben midfi...@gmail.com writes: perhaps it is too late to suggest things for GSOC -- but stephen tetley on a different thread pointed at aaron turon's work, which there's a very interesting new concurrency framework he calls reagents which seems to give the best of all worlds : it is declarative and compositional like STM, but gives performance akin to hand-coded lock-free data structures. he seems to have straddled the duality of isolation vs message-passing nicely, and can subsume things like actors and the join calculus. http://www.ccs.neu.edu/home/turon/reagents.pdf he has a BSD licensed library in scala at https://github.com/aturon/ChemistrySet if someone doesn't want to pick this up for GSOC i might have a hand at implementing it myself. Keep use in the loop if you do. I have a very nice application that has been needing a nicer approach to concurrency than IORefs but really can't afford STM. Cheers, - Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I Need a Better Functional Language!
On Thu, Apr 5, 2012 at 11:59 AM, Tillmann Rendel ren...@informatik.uni-marburg.de wrote: Paul R wrote: I am curious what are interesting use-cases for that? Symbolic analysis? self-compilers? Optimization. For example, imagine the following definition of function composition: map f . map g = map (f . g) f . g = \x - f (g x) In Haskell, we cannot write this, because we cannot pattern match on function calls. Tillmann So, we're not talking about optimization as in Mathematical Programming but optimization in language constructs. You might want to take a look at MIN by Stephen Tse. -- -- Regards, KC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Google Summer of Code - Lock-free data structures
+1 -- the reagents model is interesting and it would be good to see a Haskell implementation. On Thu, Apr 5, 2012 at 3:05 PM, Ben Gamari bgamari.f...@gmail.com wrote: Ben midfi...@gmail.com writes: perhaps it is too late to suggest things for GSOC -- but stephen tetley on a different thread pointed at aaron turon's work, which there's a very interesting new concurrency framework he calls reagents which seems to give the best of all worlds : it is declarative and compositional like STM, but gives performance akin to hand-coded lock-free data structures. he seems to have straddled the duality of isolation vs message-passing nicely, and can subsume things like actors and the join calculus. http://www.ccs.neu.edu/home/turon/reagents.pdf he has a BSD licensed library in scala at https://github.com/aturon/ChemistrySet if someone doesn't want to pick this up for GSOC i might have a hand at implementing it myself. Keep use in the loop if you do. I have a very nice application that has been needing a nicer approach to concurrency than IORefs but really can't afford STM. Cheers, - Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I Need a Better Functional Language!
On Thu, Apr 5, 2012 at 8:59 PM, Tillmann Rendel ren...@informatik.uni-marburg.de wrote: Paul R wrote: I am curious what are interesting use-cases for that? Symbolic analysis? self-compilers? Optimization. For example, imagine the following definition of function composition: map f . map g = map (f . g) f . g = \x - f (g x) In Haskell, we cannot write this, because we cannot pattern match on function calls. Tillmann On the one hand, yes we can, with RULES: http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/rewrite-rules.html On the other hand, I've never used it, but this sounds a bit like Pure: http://code.google.com/p/pure-lang/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Testing Concurrent Programs
How do you test concurrent programs in which you actually have to test over all possible interleaving schedules by the scheduler . Is this possible to do with quickcheck . Thanks , Satvik ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
