Re: [Haskell-cafe] GHC 7.0.1 developer challenges

[Anders Kaseorg]

On Sat, 2010-12-04 at 13:42 -0500, Brandon S Allbery KF8NH wrote:
> We went over this some time back; the GHC runtime is wrong here, it
> should only disable flags when running with geteuid() == 0.

No.  +RTS flags on the command line, at least, need to stay disabled in
all cases, not just setuid binaries.  There are many situations where
you can arrange for untrusted command line arguments to be passed to
normal non-setuid binaries running with different privileges, including
some that you might not expect, such as CGI scripts.

We can possibly be more permissive with the GHCRTS environment variable,
as long as we check that we aren’t setuid or setgid or running with
elevated capabilities, because it’s harder to cross a privilege boundary
with arbitrary environment variables.  But, as already demonstrated by
the replies, this check is hard to get right.

Anders



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

Re: [Haskell-cafe] Location of .cabal folder

[Michael Snoyman]

Thanks Antoine, exactly the information I needed!

Michael

On Wed, Dec 8, 2010 at 7:07 AM, Antoine Latter  wrote:
> Hi Michael,
>
> Cabal-install uses:
>
>> System.Directory.getAppUserDataDirectory "cabal"
>
> in the module Distribution.Client.Config.
>
> Antoine
>
> On Tue, Dec 7, 2010 at 9:52 PM, Michael Snoyman  wrote:
>> Hi all,
>>
>> I'm trying to figure out how to determine the location of the .cabal
>> folder. I'm trying to release the code powering the package dependency
>> site[1] as a standalone library/application, but currently I've simply
>> hardcoded the path to my 00-index.tar file.
>>
>> Thanks,
>> Michael
>>
>> [1] http://packdeps.haskellers.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] Location of .cabal folder

[Antoine Latter]

Hi Michael,

Cabal-install uses:

> System.Directory.getAppUserDataDirectory "cabal"

in the module Distribution.Client.Config.

Antoine

On Tue, Dec 7, 2010 at 9:52 PM, Michael Snoyman  wrote:
> Hi all,
>
> I'm trying to figure out how to determine the location of the .cabal
> folder. I'm trying to release the code powering the package dependency
> site[1] as a standalone library/application, but currently I've simply
> hardcoded the path to my 00-index.tar file.
>
> Thanks,
> Michael
>
> [1] http://packdeps.haskellers.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] Location of .cabal folder

[Michael Snoyman]

Hi all,

I'm trying to figure out how to determine the location of the .cabal
folder. I'm trying to release the code powering the package dependency
site[1] as a standalone library/application, but currently I've simply
hardcoded the path to my 00-index.tar file.

Thanks,
Michael

[1] http://packdeps.haskellers.com/

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

Re: [Haskell-cafe] Offer to mirror Hackage

[Brandon S Allbery KF8NH]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/7/10 18:53 , Darrin Chandler wrote:
> On Tue, Dec 07, 2010 at 11:04:04PM +0100, Ketil Malde wrote:
>> It's not obvious to me that adding a mirror makes the infrastructure
>> more more insecure.  Any particular concerns?  (I hope I qualify as
>> naïve here :-)
> 
> If you run a mirror people will come to you for software to run on their
> machines. I see a way to take advantage of that immediately.

Exactly.  And this isn't theoretical; fake packages and packages with extra
payloads injected into them are fairly common.

- -- 
brandon s. allbery [linux,solaris,freebsd,perl]  allb...@kf8nh.com
system administrator  [openafs,heimdal,too many hats]  allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon university  KF8NH
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkz/AMYACgkQIn7hlCsL25WCuwCgyuhbb6Q1eMbatUX5mxDp6Avi
dDoAnj49sj73cDTVp0+8BXxi6oir3zAq
=x2Gr
-END PGP SIGNATURE-

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

Re: [Haskell-cafe] Conditional compilation for different versions of GHC?

[Brandon S Allbery KF8NH]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/7/10 06:00 , Henning Thielemann wrote:
> Brandon S Allbery KF8NH wrote:
>> Since the base package is (with good reason) part of the compiler, anyone
>> smart enough to get that to work is smart enough to edit the cabal file.
> 
> There are good reasons for not only bundling 'ghc' package with GHC, but
> 'base', too? I assumed it is intended to untangle 'base' and GHC in future,
> such that 'base' can be used with JHC, UHC, Hugs.

I seem to recall that the logistics of that change have been proving a bit
difficult in practice, and as such it's probably not going to happen very soon.

- -- 
brandon s. allbery [linux,solaris,freebsd,perl]  allb...@kf8nh.com
system administrator  [openafs,heimdal,too many hats]  allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon university  KF8NH
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkz+9HYACgkQIn7hlCsL25XXPQCfa/x9ZyhUmN88vu3/EPv8Tjhq
+5EAniBq3G9gto/IC8kyYFP2rAjTxB/4
=LnDx
-END PGP SIGNATURE-

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

Re: [Haskell-cafe] Question: mime-mail and base64 encoding

[Brandon S Allbery KF8NH]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/7/10 01:21 , Nathan Howell wrote:
> The way I've seen it done before was to:
> - calculate the size of the body in quoted-printable and base64 encoding
> - select the smaller encoded form of the two
> 
> quoted-printable is fairly human readable. This strategy also works
> for encoding headers, particularly Subject: lines (substituting
> q-encoding for qp).

"Quoted-Printable: a standard for mangling Internet messages
 Quoted-Unreadable: the result of applying said standard
 Unquoted-Unprintable: the comments from the recipients of the above"

(me, in alt.sysadmin.recovery.  I'm not sure how someone converted "Brandon
S Allbery KF8NH" into "bf8" but that's the universal attribution.)

- -- 
brandon s. allbery [linux,solaris,freebsd,perl]  allb...@kf8nh.com
system administrator  [openafs,heimdal,too many hats]  allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon university  KF8NH
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkz+87kACgkQIn7hlCsL25U+FQCgzV+47Rl5KB7ZreKMyRx4kDhb
6kMAmgJy8TW0omQyDuSMp5oaYOctnSDh
=Si8I
-END PGP SIGNATURE-

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

Re: [Haskell-cafe] Offer to mirror Hackage

[Darrin Chandler]

On Tue, Dec 07, 2010 at 11:04:04PM +0100, Ketil Malde wrote:
> It's not obvious to me that adding a mirror makes the infrastructure
> more more insecure.  Any particular concerns?  (I hope I qualify as
> naïve here :-)

If you run a mirror people will come to you for software to run on their
machines. I see a way to take advantage of that immediately.

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

Re: [Haskell-cafe] Offer to mirror Hackage

[Ketil Malde]

Brandon S Allbery KF8NH  writes:

>> IMO, mirroring is orthogonal to that, too.

> Only if you consider security a minor or non-issue.  

What I mean is that you can mirror a repository regardless of whether
packages are signed or not.

> I'm tempted to say anyone who believes that on the modern Internet is
> at best naïve.

It's not obvious to me that adding a mirror makes the infrastructure
more more insecure.  Any particular concerns?  (I hope I qualify as
naïve here :-)

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants

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

[Haskell-cafe] Fwd: second call for papers: LDTA 2011 / ETAPS

[Paul Brauner]

-- Forwarded message --
From: Emilie Balland 
Date: Tue, Dec 7, 2010 at 10:35 PM
Subject: second call for papers: LDTA 2011 / ETAPS
To: "Paul.Brauner" 


   LDTA 2011 Call for Papers and Tool Challenge Submissions

   11th International Workshop on
   Language Descriptions, Tools, and Applications

www.ldta.info

Saarbrucken, Germany
 March 26 & 27, 2011
  an ETAPS workshop

LDTA is an application and tool-oriented workshop focused on
grammarware - software based on grammars in some form. Grammarware
applications are typically language processing applications and
traditional examples include parsers, program analyzers, optimizers
and translators.  A primary focus of LDTA is grammarware that is
generated from high-level grammar-centric specifications and thus
submissions on parser generation, attribute grammar systems,
term/graph rewriting systems, and other grammar-related
meta-programming tools, techniques, and formalisms are encouraged.

LDTA is also a forum in which theory is put to the test, in many cases
on real-world software engineering challenges. Thus, LDTA also
solicits papers on the application of grammarware to areas including,
but not limited to, the following:
- program analysis, transformation, generation, and verification,
- implementation of Domain-Specific Languages,
- reverse engineering and re-engineering,
- refactoring and other source-to-source transformations,
- language definition and language prototyping, and
- debugging, profiling, IDE support, and testing.

This year LDTA will also be putting theory, as well as techniques and
tools, to the test in a new way - in the LDTA Tool Challenge. Tool
developers are invited to participate in the Challenge by developing
solutions to a range of language processing tasks over a simple but
evolving set of imperative programming languages.  Tool challenge
participants will present highlights of their solution during a
special session of the workshop and contribute to a joint paper on the
Tool Challenge and proposed solutions to be co-authored by all
participants after the workshop.

Note that LDTA is a well-established workshop similar to other
conferences on (programming) language engineering topics such as SLE
and GPCE, but is solely focused on grammarware.

Paper Submission

LDTA solicits papers in the following categories.

- research papers: original research results within the scope of LDTA
 with a clear motivation, description, analysis, and evaluation.

- short research papers: new innovative ideas that have not been
 completely fleshed out.  As a workshop, LDTA strongly encourages
 these types of submissions.

- experience report papers: description of the use of a grammarware
 tool or technique to solve a non-trivial applied problem with an
 emphasis on the advantages and disadvantages of the chosen approach
 to the problem.

- tool demo papers: discussion of a tool or technique that explains
 the contributions of the tool and what specifically will be
 demonstrated.  These papers should describe tools and applications
 that do not fit neatly into the specific problems in the Tool
 Challenge.

Each submission must clearly state in which of these categories it
falls and not be published or submitted elsewhere.  Papers are to use
the standard LaTeX article style and the authblk style for
affiliations; a sample of which is provided at www.ldta.info.
Research and experience papers are limited to 15 pages, tool
demonstration papers are limited to 10 pages, and short papers are
limited to 6 pages.  The final version of the accepted papers will,
pending approval, be published in the ACM Digital Library and will
also be made available during the workshop.

Please submit your abstract and paper using EasyChair at
http://www.easychair.org/conferences/?conf=ldta2011.

The authors of each submission are required to give a presentation at
LDTA 2011 and tool demonstration paper presentations are intended to
include a significant live, interactive demonstration.

The authors of the best papers will be invited to write a journal
version of their paper which will be separately reviewed and, assuming
acceptance, be published in journal form.  As in past years this will
be done in a special issue of the journal Science of Computer
Programming (Elsevier Science).

Invited Speaker
---
Rinus Plasmeijer, Radboud University Nijmegen, The Netherlands

Important Dates
---
Abstract submission: Dec. 15, 2010
Full paper submission: Dec. 22, 2010
Author notification: Feb. 01, 2011
Camera-ready papers due: TBD
LDTA Workshop: March 26-27, 2011

LDTA Tool Challenge
---

The aim of the LDTA Tool Challenge is to foster a better
understanding, among tool developers and tool users, of relative
strengths and weaknesses of different language processing tool
techniques as well 

Re: [Haskell-cafe] Printing of asynchronous exceptions to stderr

[Mitar]

Hi!

On Wed, Dec 1, 2010 at 10:50 AM, Simon Marlow  wrote:
>> Yes, but semantics are different. I want to tolerate some exception
>> because they are saying I should do this and this (for example user
>> interrupt, or timeout) but I do not want others, which somebody else
>> maybe created and I do not want to care about them.
>
> Surely if you don't care about these other exceptions, then the right thing
> to do is just to propagate them?  Why can't they be dealt with in the same
> way as user interrupt?

The problem is that Haskell does not support getting back to
(continue) normal execution flow as there was no exception. So for
user interrupt I want to deal with in a way to interrupt execution,
cleanup, print to user something, etc. But for other exceptions I want
to behave as nothing happened. This is why those cannot be dealt with
the same as user interrupt.

On way to "behave as nothing happened" is to mask them (and only them)
and the other way is to "eat" (and ignore) them. Probably the first
would be better if it would be possible. So the second one is the one
I have chosen.

The third one, to restore execution flow is sadly not possible in
Haskell. Would it be possible to add this feature? To have some
function which operates on Exception value and can get you back to
where the exception was thrown?

>> uninterruptible :: IO a ->  IO a
>> uninterruptible a = *CENSORED*
>
> That is a very scary function indeed.  It just discards all exceptions and
> re-starts the operation.  I definitely do not condone its use.

Yes, this one is extreme. For example, this would be more in the line
of above arguments:

uninterruptible :: IO a -> IO a
uninterruptible a = mask_ $ a `catches` [
Handler (\(e :: AsyncException) -> case e of UserInterrupt ->
throw e ; _ -> uninterruptible a),
Handler (\(_ :: SomeException) -> uninterruptible a)
  ]

Mitar

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

Re: [Haskell-cafe] Offer to mirror Hackage

[Duncan Coutts]

On 4 December 2010 16:31, Dan Knapp  wrote:
> With Hackage down, now seemed like a good time to push this issue
> again.  It's such an important site to us that it's really rather a
> shame there are no mirrors of it.  I have a personal-and-business
> server in a data center in Newark, with a fair chunk of bandwidth,
> which I'd like to offer for a permanent mirror.  Is there interest in
> this?  Who do I need to talk to for it to happen?

At the recent hackathon we were working on hackage mirroring.

By this we do not mean just using rsync to sync the current
combination of filestore + cgi programs that make up the current
hackage implementation. We want to make it easy to set up dumb or
smart package archives and to do nearly-live mirroring.

We have a pototype hackage-mirror client that can poll two servers and
copy packages from one instance to the other. This assumes the target
is a smart mirror (e.g. an instance of the new hackage-server impl).
We also need to be able to target local "dumb" mirrors that are just
passive collections of files.

> Strategy-wise, I think the best approach is round-robin DNS, since
> that's transparent to the end user - everything would still appear at
> the URL it's at now, but behind-the-scenes magic would let things keep
> working when one or the other site is down.  I haven't personally set
> up such a system before but I'm willing to take on the burden of
> figuring it out.

This is a somewhat orthogonal issue since I think you're talking about
multiple master smart servers that can accept uploads.

Duncan

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

Re: [Haskell-cafe] An Haskell implementation of a sweep line algorithm for the detection of segments intersection

[Henning Thielemann]

On Mon, 6 Dec 2010, vince vegga wrote:


Hi,

Here is my Haskell implementation of the Shamos and Hoey algorithm for
detecting segments intersection in the plane:

http://neonstorm242.blogspot.com/2010/12/sweep-line-algorithm-for-detection
-of.html

I'm new to Haskell, so any useful comments will be appreciated.


In sweepLine, things like

  | a = False
  | otherwise = x

can be written as (not a && x) and

  if a then True else x

as (a || x).


In handleLeftEndpoint you can create (events,updateLine) outside the case 
analysis, since this is common to all cases.


In general you can find hints in:
  http://www.haskell.org/haskellwiki/Haskell_programming_tips
 and in
  http://www.haskell.org/haskellwiki/Category:Style

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

Re: [Haskell-cafe] Offer to mirror Hackage

[Brandon S Allbery KF8NH]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/7/10 08:07 , Ketil Malde wrote:
> Dan Knapp  writes:
>> I agree that signed packages are a good idea.  We should move with all
>> haste to implement them.  But I'm not sure we want to hold up
>> everything else while we wait for that.  
> 
> IMO, mirroring is orthogonal to that, too.

Only if you consider security a minor or non-issue.  I'm tempted to say
anyone who believes that on the modern Internet is at best naïve.  (Although
admittedly security is one of my work foci.)

- -- 
brandon s. allbery [linux,solaris,freebsd,perl]  allb...@kf8nh.com
system administrator  [openafs,heimdal,too many hats]  allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon university  KF8NH
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkz+k3YACgkQIn7hlCsL25W7PACdHUuh5zaPZeBTprMvN+HcLslu
VV0AoJVgmDbBZyZtcX57fGWkGeW2dT/3
=Gqlm
-END PGP SIGNATURE-

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

Re: [Haskell-cafe] LLVM, type-level?

[Lally Singh]

On Tue, Dec 7, 2010 at 1:31 PM, Henning Thielemann
 wrote:
>
> On Tue, 7 Dec 2010, Lally Singh wrote:
>
>> Hey all,
>>
>>  I'm generating a structure definition from input, and would like to
>> generate some LLVM code that can use it.  I see an 'alloca' function
>> in LLVM.Core that may do the trick, but takes a static type (Ptr a),
>> which I wouldn't have.  Is there a dynamic variant?  I'm currently
>> generating a TypeDesc Struct type.
>
>  How much flexibility do you need? Is the user really allowed to specify an
> arbitrary 'struct' declaration? This could be a security hole.
>  If you really want it, I think you would have to use existential
> quantification in order to construct a user defined type at runtime.

Yeah, the program will take in a declaration of a (basic) struct, with
doubles, floats, and integer members.  It'll generate an LLVM program
that'll read that sort of struct from a shared memory segment.

>> Also, is everything under LLVM.Core.* private (not LLVM.Core, but
>> LLVM.Core.Util,etc)?  I saw from some blog posts that Core.Util has a
>> function for (I think) getting the a function's parameters, but I
>> can't seem to find a way to access it.  Is there another way to get
>> the arguments to a function?
>
> I do not understand. The example you posted recently, was a function with
> parameters. Isn't that what you need?

I'd like to get the runtime arguments of a function.  In my case,
main()'s command-line arguments to get the shared-memory ID.

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

Re: [Haskell-cafe] Bifold: a simultaneous foldr and foldl

[Henning Thielemann]

Noah Easterly wrote:

Somebody suggested I post this here if I wanted feedback.

So I was thinking about the ReverseState monad I saw mentioned on r/haskell a 
couple days ago, and playing around with the concept of information flowing 
two directions when I came up with this function:


bifold :: (l -> a -> r -> (r,l)) -> (l,r) -> [a] -> (r,l)
bifold _ (l,r) [] = (r,l)
bifold f (l,r) (a:as) = (ra,las)
 where (ras,las) = bifold f (la,r) as
 (ra,la) = f l a ras

(I'm sure someone else has come up with this before, so I'll just say I 
discovered it, not invented it).


Basically, it's a simultaneous left and right fold, passing one value from 
the start of the list toward the end, and one from the end toward the start.


I also needed a bidirectional fold in the past. See foldl'r in
  http://code.haskell.org/~thielema/utility/src/Data/List/HT/Private.hs

You can express it using foldr alone, since 'foldl' can be written as 'foldr':
   http://www.haskell.org/haskellwiki/Foldl_as_foldr

You may add your example to the Wiki.


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

Re: [Haskell-cafe] LLVM, type-level?

[Henning Thielemann]

On Tue, 7 Dec 2010, Lally Singh wrote:


Hey all,

 I'm generating a structure definition from input, and would like to
generate some LLVM code that can use it.  I see an 'alloca' function
in LLVM.Core that may do the trick, but takes a static type (Ptr a),
which I wouldn't have.  Is there a dynamic variant?  I'm currently
generating a TypeDesc Struct type.


 How much flexibility do you need? Is the user really allowed to specify 
an arbitrary 'struct' declaration? This could be a security hole.
 If you really want it, I think you would have to use existential 
quantification in order to construct a user defined type at runtime.



Also, is everything under LLVM.Core.* private (not LLVM.Core, but
LLVM.Core.Util,etc)?  I saw from some blog posts that Core.Util has a
function for (I think) getting the a function's parameters, but I
can't seem to find a way to access it.  Is there another way to get
the arguments to a function?


I do not understand. The example you posted recently, was a function with 
parameters. Isn't that what you need?


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

Re: [Haskell-cafe] ANN: hledger 0.13

[Simon Michael]

Hi Peter,

no reason as far as hledger and hledger-lib is concerned, but one of  
the add-on packages, which depends on them, also requires process  
1.0.1.4. If you install hledger or hledger-lib with the older version  
of process, then cabal is not able to install the add-on package.  
Sorry for the inconvenience, there are probably more such cases and  
I'm not sure how to handle it better.


-Simon

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

Re: [Haskell-cafe] Question: mime-mail and base64 encoding

[Michael Snoyman]

On Tue, Dec 7, 2010 at 8:21 AM, Nathan Howell  wrote:
> On Mon, Dec 6, 2010 at 8:42 PM, Michael Snoyman  wrote:
>> The request is to make both the HTML and plain text parts use base64
>> encoding by default. This *seems* to me to make a lot of sense, since
>> it will ensure that your message arrives exactly as you intended it,
>> and will ensure that any non-ASCII code points don't get killed
>> somewhere along the way. On the other hand, I'm not sure what client
>> support is like for base-64 encoding. Don't we need to leave *some*
>> form of non-encoded data for less sophisticated email clients?
>
> The way I've seen it done before was to:
> - calculate the size of the body in quoted-printable and base64 encoding
> - select the smaller encoded form of the two
>
> quoted-printable is fairly human readable. This strategy also works
> for encoding headers, particularly Subject: lines (substituting
> q-encoding for qp).
>

Seems like quoted-printable *is* the correct answer here. I've
implemented both that and encoded-word for headers, and the code seems
to work just fine. Of course, testing by everyone else is always
welcome; the code is in my github repo[1].

Now I have some design questions for everyone:

* There does not appear to be a way to encode MIME header *keys*, so
it's entirely possible that mime-mail will generate invalid messages.
Is this something to worry about? It basically means the user shot
him/herself in the foot by putting non-ASCII data in the key, but even
so it feels wrong that the type system isn't helping us at all here.

* Internally the header values all get converted to Text values for
processing. Does it make sense to just make all the records in the
Mail and Part datatypes use Text instead of String? Especially given
OverloadedStrings it should not hurt usability too much, and in theory
will help performance a bit.

Since I have breaking changes in the API from a previous commit, the
new version will be mime-mail 0.1.0. As long as we're breaking things,
does anyone have anything else they'd like to throw in?

Michael

[1] https://github.com/snoyberg/mime-mail

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

[Haskell-cafe] LLVM, type-level?

[Lally Singh]

Hey all,

  I'm generating a structure definition from input, and would like to
generate some LLVM code that can use it.  I see an 'alloca' function
in LLVM.Core that may do the trick, but takes a static type (Ptr a),
which I wouldn't have.  Is there a dynamic variant?  I'm currently
generating a TypeDesc Struct type.

Also, is everything under LLVM.Core.* private (not LLVM.Core, but
LLVM.Core.Util,etc)?  I saw from some blog posts that Core.Util has a
function for (I think) getting the a function's parameters, but I
can't seem to find a way to access it.  Is there another way to get
the arguments to a function?

Thanks for your help,

-Lally

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

Re: [Haskell-cafe] Help defining a Typeable polymorphic-state monad transformer

[Brandon Simmons]

On Mon, Dec 6, 2010 at 11:53 PM, Luke Palmer  wrote:
> This has nothing to do with a monad.  This is just about data.  You
> want a type that can contain any Typeable type, and a safe way to cast
> out of that type into the type that came in.  Such a thing exists,
> it's called Data.Dynamic.
>
> Then your monad is just StateT Dynamic, where your magical maybeifying get is:
>
> getD :: (Monad m, Typeable a) => StateT Dynamic m a
> getD = maybe (fail "Type error") return . cast =<< get
>
> Luke
>

Thanks a lot, Luke. I'd never run across Data.Dynamic before, but
figured something like this existed. Looks perfect.

Thanks so much,
Brandon


> On Mon, Dec 6, 2010 at 9:09 PM, Brandon Simmons
>  wrote:
>> Hi all,
>>
>> I gave myself until this evening to figure this out on my own, and
>> time is up! Hopefully this makes for a good discussion, though the
>> idea could be dumb.
>>
>> What I'm trying to do is define a state monad in which the passed
>> state can change type during the computation. The only constraint is
>> that the state types must always be of the Typeable class (see:
>> http://hackage.haskell.org/packages/archive/base/latest/doc/html/Data-Typeable.html
>> ).
>>
>> The idea is that the new monad would be something like 'StateT s Maybe
>> a', but where the 's' type is not fixed (indeed is hidden in an
>> existential type) and where any programmer errors in the chaining of
>> the polymorphic state will be caught in the Maybe type (or really the
>> 'fail' implementation of any monad).
>>
>> Here is how I imagine a computation might look:
>>
>>    computation :: TypeableState Maybe String
>>    computation = do
>>        (c:cs) <-  getTS
>>        putTS (length cs)
>>        return ("c" ++ " was the first letter of the string passed as
>> initial state.")
>>
>> So TypeableState is very similar to StateT, except that the state type
>> is not present as a type argument. In the example above 'Maybe' is the
>> monad that catches Typeable errors, and String is the return type of
>> the computation.
>>
>> getTS and putTS would be get and put functions that constrain their
>> arguments to the Typeable class.
>>
>> Here is what I have so far (at least this is my most recent
>> uncommented attempt):
>>
>>> {-# LANGUAGE ExistentialQuantification #-}
>>> module Main
>>>       where
>>>
>>> import Control.Monad.State
>>> import Data.Typeable
>>>
>>> -- we might have restricted our 'm' to MonadPlus and used the explicit
>>> -- 'mzero', but decided instead to use Monad, with 'fail'. This is
>>> -- more appropriate since we won't be using 'mplus'. See 'liftMaybe'.
>>> data TypeableState m a = forall s0 sN. (Typeable s0, Typeable sN)=>
>>>                            TypeableState (s0 -> m (a,sN))
>>>
>>> -- this is probably one of the more non-sensical attempts I've made at
>>> -- this... but I'm not sure:
>>> runTypeableState :: (Monad m, Typeable s0, Typeable sN)=> TypeableState m a 
>>> -> s0 -> m (a,sN)
>>> runTypeableState (TypeableState st) s0 = (liftMaybe $ cast s0) >>= st
>>>
>>> -- copied from Control.Monad.StateT
>>> instance (Monad m) => Monad (TypeableState m) where
>>>     return a = TypeableState $ \s -> return (a, s)
>>>     m >>= k  = TypeableState $ \s -> do
>>>         ~(a, s') <- runTypeableState m s
>>>         runTypeableState (k a) s'
>>>     fail str = TypeableState $ \_ -> fail str
>>>
>>> -- I imagine using this with 'cast' to thread the type in our monad
>>> -- transformer
>>> liftMaybe :: (Monad m)=> Maybe a -> m a
>>> liftMaybe = maybe (fail "Monadic failure") return
>>
>> So is this even feasible? Or do I not grok what we can and can't do
>> with the Typeable class?
>>
>> Any thoughts on this are appreciated.
>>
>> Sincerely,
>> Brandon Simmons
>> http://coder.bsimmons.name
>>
>> ___
>> 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] Ed Lambda: Functional programming meetup in Edinburgh

[Ollie Saunders]

It's that time again...

When: Monday the 13th of December at 7:00pm
Where: 12a The Outhouse, Broughton Street Lane, Edinburgh

This month Chris Yocum will be talking about some functional
fundamentals with his talk:
The Loopless Loop: Perl and Ocaml as functional programming languages

Phil Scott may also be talking, we're not sure yet. Also I'm not sure
if I'm going to be able to make it but I've made provisions if I can't
so the show will definitely be going on.

As always there will be plenty of beer and friendly banter. I think
everyone who comes enjoys themselves and learns something.

If you missed out on last month then you can see my talk on Vimeo:
 (2nd part isn't there yet but is uploading
right now).

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

Re: [Haskell-cafe] Question: mime-mail and base64 encoding

[Nicolas Pouillard]

On Mon, 6 Dec 2010 22:21:35 -0800, Nathan Howell  
wrote:
> On Mon, Dec 6, 2010 at 8:42 PM, Michael Snoyman  wrote:
> > The request is to make both the HTML and plain text parts use base64
> > encoding by default. This *seems* to me to make a lot of sense, since
> > it will ensure that your message arrives exactly as you intended it,
> > and will ensure that any non-ASCII code points don't get killed
> > somewhere along the way. On the other hand, I'm not sure what client
> > support is like for base-64 encoding. Don't we need to leave *some*
> > form of non-encoded data for less sophisticated email clients?
> 
> The way I've seen it done before was to:
> - calculate the size of the body in quoted-printable and base64 encoding
> - select the smaller encoded form of the two
> 
> quoted-printable is fairly human readable. This strategy also works
> for encoding headers, particularly Subject: lines (substituting
> q-encoding for qp).

I would prefer quoted-printable as well, at least for the text alternative.

-- 
Nicolas Pouillard
http://nicolaspouillard.fr

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

Re: [Haskell-cafe] Offer to mirror Hackage

[Ketil Malde]

Dan Knapp  writes:

> I agree that signed packages are a good idea.  We should move with all
> haste to implement them.  But I'm not sure we want to hold up
> everything else while we wait for that.  

IMO, mirroring is orthogonal to that, too.

> That's also my take on a peer-peer repository, as I said already.  

Do you mean a two-way sync here?  I think it'd be way easier to just set
up a slave repo using rsync, and let people edit their .cabal/configs.
But I don't really know the internals, perhaps there are implementation
details of cabal or hackage that complicates this?

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants

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

Re: [Haskell-cafe] ANN: hledger 0.13

[Peter Simons]

Hi Simon,

thank you very much for your efforts. I wonder whether there is any
particular reason why hledger won't build with process-1.0.1.3?

Take care,
Peter


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

Re: [Haskell-cafe] Categorical description of systems with dependent types

[Petr Pudlak]

Hi,

thanks to all who gave me valuable pointers to what to study. It will 
take me some time to absorb that, but it helped a lot.


Best regards,
Petr

On Thu, Dec 02, 2010 at 02:25:41PM -0500, Dan Doel wrote:

On Thursday 02 December 2010 10:13:32 am Petr Pudlak wrote:

  Hi,

recently, I was studying how cartesian closed categories can be used to
describe typed functional languages. Types are objects and morphisms are
functions from one type to another.

Since I'm also interested in systems with dependent types, I wonder if
there is a categorical description of such systems. The problem (as I
see it) is that the codomain of a function depends on a value passed to
the function.

I'd happy if someone could give me some pointers to some papers or other
literature.


There are many different approaches to modelling dependent types in category
theory. Roughly, they are all similar to modelling logic, but they all differ
in details.

I think the easiest one to get a handle on is locally Cartesian closed
categories, although there's some non-intuitive stuff if you're used to type
theory. The way it works is this: a locally Cartesian closed category C is a
category such that all its slice categories are cartesian closed. This gets
you the following stuff:

---

Since C is isomorphic to C/1, where 1 is a terminal object, C is itself
Cartesian closed assuming said 1 exists. This may be taken as a defining
quality as well, I forget.

---

Each slice category C/A should be viewed as the category of A-indexed families
of types. This seems kind of backwards at first, since the objects of C/A are
pairs like (X, f : X -> A). However, the way of interpreting such f as a
family of types F : A -> * is that F a corresponds to the 'inverse image' of f
over a. So X is supposed to be like the disjoint union of the family F in
question, and f identifies the index of any particular 'element' of X.

Why is this done? It has nicer theoretical properties. For instance, A -> *
can't sensibly be a morphism, because * corresponds to the entire category of
types we're modelling. It'd have to be an object of itself, but that's
(likely) paradox-inducing.

---

Given a function f : B -> A, there's a functor f* : C/A -> C/B, which re-
indexes the families. If you think of this in the more usual type theory
style, it's just composition: B -f-> A -F-> *. In the category theoretic case,
it's somewhat more complex, but I'll just leave it at that for now.

Now, this re-indexing functor is important. In type theories, it's usually
expected to have two adjoints:

 Σf ⊣ f* ⊣ Πf

These adjoints are the dependent sum and product. To get a base type that
looks like:

 Π x:A. B

from type theory. Here's how we go:

 B should be A-indexed, so it's an object of C/A

 For any A, there's an arrow to the terminal object ! : A -> 1

 This induces the functor !* : C/1 -> C/A

 This has an adjoint Π! : C/A -> C/1

 C/1 is isomorphic to C, so C has an object that corresponds to Π!B, which is
 the product of the family B. This object is the type Π x:A. B

In general, ΠfX, with f : A -> B, and X an A-indexed family, F : A -> *, is
the B-indexed family, G : B -> * for ease, where G b = Π x : f⁻¹ b. F x. That
is, the product of the sub-family of X corresponding to each b. In the case of
B = 1, this is the product of the entire family X.

This adjointness stuff is (no surprise) very similar to the way quantifiers
are handled in categorical logic.

---

That's the 10,000 foot view. I wouldn't worry if you don't understand much of
the above. It isn't easy material. In addition to locally Cartesian closed
categories, you have:

 toposes
 hyperdoctrines
 categories with families
 contextual categories
 fibred categories

And I'm probably forgetting several. If you read about all of these, you'll
probably notice that there are a lot of similarities, but they mostly fail to
be perfectly reducible to one another (although toposes are locally Cartesian
closed).

I don't have any recommendations on a best introduction for learning this.
Some that I've read are:

 From Categories with Families to Locally Cartesian Closed Categories
 Locally Cartesian Closed Categories and Type Theory

but I can't say that any one paper made everything snap into place. More that
reading quite a few gradually soaked in. And I still feel rather hazy on the
subject.

Hope that helps some.

-- Dan


signature.asc
Description: Digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe