Re: [Haskell-cafe] function arithmetic?
Might not be exactly what you're looking for, but Control.Arrow has a rich set of operators that can be used to combine functions. For instance, there's an example on http://en.wikibooks.org/wiki/Haskell/Understanding_arrows showing an addA function that can be used to apply two functions to the same argument and add the results: Prelude import Control.Arrow Prelude Control.Arrow let addA f g = f g arr (\ (y, z) - y + z) Prelude Control.Arrow addA (+2) (*5) 10 62 If you're set on using the + and * operators, I'm guessing it's not possible to define a (sane) instance of Num for (-), but it would probably be instructive to try. On Sat, Aug 31, 2013 at 10:01 PM, Christopher Howard christopher.how...@frigidcode.com wrote: Hi. I was just curious about something. In one of my math textbooks I see expressions like this f + g or (f + g)(a) where f and g are functions. What is meant is f(a) + g(a) Is there a way in Haskell you can make use of syntax like that (i.e., expressions like f + g and f * g to create a new function), perhaps by loading a module or something? __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://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] Can I use String without in ghci?
I want to know if it is possible that I use strings without . If I type *Preludefoo bar* which actually I mean *Preludefoo bar* However I don't want to type s. I have noticed if *bar* is predefined or it is a number, it can be used as arguments. But can other strings be used this way? Like in bash, we can use *ping 127.0.0.1* where *127.0.0.1* is an argument. If not, can *foo* be defined as a function so that it recognize arguments like *bar* as *bar*? Thanks, Yi Lu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] function arithmetic?
Yes, you can do that, but you probably shouldn't. See also: http://www.haskell.org/haskellwiki/Num_instance_for_functions http://hackage.haskell.org/package/applicative-numbers On Sat, Aug 31, 2013 at 10:01 PM, Christopher Howard christopher.how...@frigidcode.com wrote: Hi. I was just curious about something. In one of my math textbooks I see expressions like this f + g or (f + g)(a) where f and g are functions. What is meant is f(a) + g(a) Is there a way in Haskell you can make use of syntax like that (i.e., expressions like f + g and f * g to create a new function), perhaps by loading a module or something? __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://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] Can I use String without in ghci?
On 01/09/13 07:02, yi lu wrote: I want to know if it is possible that I use strings without . If I type *Preludefoo bar* which actually I mean *Preludefoo bar* However I don't want to type s. I have noticed if *bar* is predefined or it is a number, it can be used as arguments. But can other strings be used this way? Like in bash, we can use *ping 127.0.0.1* where *127.0.0.1* is an argument. If not, can *foo* be defined as a function so that it recognize arguments like *bar* as *bar*? Thanks, Yi Lu You can't do this non-trivially. I think your only bet would be Template Haskell using the second approach and even then, it's a huge, huge stretch. I highly recommend against such ideas though. Do you really want anything that's not bound to be treated as a String? (The answer is ‘no’). I suggest that you get used to ‘’s. If you have deep hatred for ‘’, you could resort to spelling out the strings like ['f', 'o', 'o'] or even 'f':'o':'o':[]. It's a bit like asking whether you can do addition everywhere by just typing the numbers to each other (no cheating and defining number literals as functions ;) ). -- Mateusz K. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] function arithmetic?
* Christopher Howard christopher.how...@frigidcode.com [2013-08-31 21:01:38-0800] Hi. I was just curious about something. In one of my math textbooks I see expressions like this f + g or (f + g)(a) where f and g are functions. What is meant is f(a) + g(a) Is there a way in Haskell you can make use of syntax like that (i.e., expressions like f + g and f * g to create a new function), perhaps by loading a module or something? Not the syntax, but the notion itself corresponds exactly to idiom brackets/applicative functors. In this case it's the Reader applicative. Roman signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] function arithmetic?
To clarify in Bobs remark : while you're still learning Haskell and the
type system , things like lifted Num on functions can lead to some
potentially confusing type errors.
That said, it's absolutely doable, and can be a very nice / powerful tool
when used appropriately.
On Sunday, September 1, 2013, Bob Ippolito wrote:
Yes, you can do that, but you probably shouldn't.
See also:
http://www.haskell.org/haskellwiki/Num_instance_for_functions
http://hackage.haskell.org/package/applicative-numbers
On Sat, Aug 31, 2013 at 10:01 PM, Christopher Howard
christopher.how...@frigidcode.com javascript:_e({}, 'cvml',
'christopher.how...@frigidcode.com'); wrote:
Hi. I was just curious about something. In one of my math textbooks I see
expressions like this
f + g
or
(f + g)(a)
where f and g are functions. What is meant is
f(a) + g(a)
Is there a way in Haskell you can make use of syntax like that (i.e.,
expressions like f + g and f * g to create a new function), perhaps by
loading a module or something?
__**_
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org javascript:_e({}, 'cvml',
'Haskell-Cafe@haskell.org');
http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://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] function arithmetic?
On 08/31/2013 09:27 PM, Charlie Paul wrote: I believe that this is what you want: http://www.haskell.org/haskellwiki/Num_instance_for_functions On Sat, Aug 31, 2013 at 10:01 PM, Christopher Howard christopher.how...@frigidcode.com wrote: The author seemed to be subtly mocking the idea. It seemed to be suggesting that a Num instance for functions would imply the need for constant number functions, which leads to difficulties. But I don't see why one would have to take it that far. In any case, I just tried the NumInstances package from Hackage and it seems to work great. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On Markdown in Haddock and why it's not going to happen
On 01/09/13 04:27, Mateusz Kowalczyk wrote: It doesn't have to be 1-to-1 but the features have to be expressible in both: it's useless if we have different features with one syntax but not the other. I don't find that useless. Markdown does not have definition lists, but we use a normal list to achieve the same documentation goals. Already being able to simply write basic markdown would bring me big practical benefits, and I would prefer minor theoretical misalignments not to outweigh them. If Markdown can do something new, that something can be added; if something doesn't make sense in Haddock (like horizontal rules), we ignore them. This is precisely what I have been doing and why my post went over every point from the original Markdown documentation, talking about why each of these does or doesn't make sense. In the end, Markdown offers us nothing new feature wise If the features are the same, I would prefer to write them in markdown. and either forces us to make up new syntax for things it doesn't know about (definition lists) or makes us remove existing features all together. As I said, I think it doesn't matter. The basic functionality that people use is all there. I have not seen a haddock definition list in my life, the first one is encountered is the single one in attoparsec because I grepped for [@ after reading your post. As for which markdown implementation to use: I think it really doesn't matter that much in practice. Github and pandoc can both render documentation to my pleasing; I have yet to find a difference between them that would be a practical problem for my documentation efforts. Unfortunately it _does_ matter in practice because each flavour solves Markdown quirks differently. On top of this, we have to accomodate for Haddock specific features. We're effectively creating our own flavour of Markdown + extra syntax. This sounds like… Haddock markup! Once we have picked one of the flavours, I do not care about the others. These quirks have little practical relevance: I have put the markdown from my main github projects into the tool you mentioned, and into pandoc, and there were no bad surprises for me. Given that, even if I were to step into a pathologic case, after I write the documentation, a quick look at it immediately tells me whether everything is to my liking or not. Regarding module and type links: They are links, so probably just representing them as Markdown links would be cleanest. [SomeThing]() with an empty reference could make haddock automatically figure out what is wanted or default to a type, and you could be explicit with [SomeThing](module), [SomeThing](type) and [SomeThing](class). For headings, why is CPP a problem? CPP ignores haddock comments, haddock should ignore CPP. There is no reason to put CPP macros into comments. I have to admit that I did not explore this very carefully but you we can't simply guarantee that no one every will run CPP on their files by hand. Better safe than sorry. This is unreasonable. You also can't guarantee that nobody will run the Handlebars templating language either, or any other tool. You cannot even tell what the user wants to achieve: Should -- | You can use `#if SHELL a #else b #endif` go into the documentation unexpanded or template processed? The only sane way is to make haddock agnostic of all those tools in the world, save the Haskell compiler which it addresses by being inside comments. If somebody wanted to run their custom tool by hand before running haddock by hand, sure they would write #if ... -- | Some haddock #else -- | Some other haddock # endif if they wished to conditionally generate different haddock. Regarding emphasis, **foo** would simply not be a heading in an export list. Using markdown haddock, we will have markdown headings for that. But what if I want it to be a heading? Are we picking rules arbitrarily now? I do not understand what you mean. If you want it to be a heading, you write: # My heading I don't find that worse than * My heading Markdown being claimed to be for editing documents for the Web doesn't make our efforts impossible. Pandoc can easily create latex output from it, and Github can use it as a documentation language for programming perfectly fine. So can we. That's because you can use LaTeX to render everything that HTML can (but not the other way around!). Yes, so what is the problem? You write markdown and it can be compiled to your target languages. Why is it a problem that you cannot go the other way around? My point here was saying that markdown can be compiled to the three targets you mentioned. GitHub can use it because they don't have the burden of having to accommodate for an existing feature set of a different markup language. Note how GitHub Markdown doesn't have all the features of Haddock, therefore it is _not_ compatible with it. We can't just use their Markdown because
Re: [Haskell-cafe] Can I use String without in ghci?
On 13-09-01 02:02 AM, yi lu wrote: I have noticed if *bar* is predefined or it is a number, it can be used as arguments. But can other strings be used this way? Like in bash, we can use *ping 127.0.0.1* where *127.0.0.1* is an argument. Does Bash have a rich type system, like Haskell? Does Haskell use $joy to refer to a variable, and joy to not refer to a variable, like Bash? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can I use String without in ghci?
On 13-09-01 02:41 AM, Mateusz Kowalczyk wrote: It's a bit like asking whether you can do addition everywhere by just typing the numbers to each other (no cheating and defining number literals as functions ;) ). To your horror, common math language does some of that. When 3 and ½ are typed next to each other, i.e., 3½ it is addition. See also page 8 in http://www.cs.utexas.edu/users/EWD/ewd13xx/EWD1300.PDF or look for Invisible operators in http://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/EWD1300.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can I use String without in ghci?
Not that I really want to encourage such a stringly typed practice, but it wouldn't really be that much of a stretch. * Use haskell-src-exts[0] and haskell-src-meta[1] to make a quasiquoter that can parse Haskell syntax * Use syb[2] or some other generics to find VarE and ConE expressions. In order to use SYB with TH, you'll want th-orphans[3] * Use 'reify'[4] on the name of the variable or constructor, to see if it exists. If it doesn't[5], replace it with (LitE (StringL (nameBase name))) Shouldn't really be much code at all! :D -Michael [0] http://hackage.haskell.org/package/haskell-src-exts [1] http://hackage.haskell.org/package/haskell-src-meta [2] http://hackage.haskell.org/package/syb [3] http://hackage.haskell.org/package/th-orphans [4] http://hackage.haskell.org/packages/archive/template-haskell/latest/doc/html/Language-Haskell-TH.html#v:reify [5] http://byorgey.wordpress.com/2011/08/16/idempotent-template-haskell/ On Sat, Aug 31, 2013 at 11:41 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: On 01/09/13 07:02, yi lu wrote: I want to know if it is possible that I use strings without . If I type *Preludefoo bar* which actually I mean *Preludefoo bar* However I don't want to type s. I have noticed if *bar* is predefined or it is a number, it can be used as arguments. But can other strings be used this way? Like in bash, we can use *ping 127.0.0.1* where *127.0.0.1* is an argument. If not, can *foo* be defined as a function so that it recognize arguments like *bar* as *bar*? Thanks, Yi Lu You can't do this non-trivially. I think your only bet would be Template Haskell using the second approach and even then, it's a huge, huge stretch. I highly recommend against such ideas though. Do you really want anything that's not bound to be treated as a String? (The answer is ‘no’). I suggest that you get used to ‘’s. If you have deep hatred for ‘’, you could resort to spelling out the strings like ['f', 'o', 'o'] or even 'f':'o':'o':[]. It's a bit like asking whether you can do addition everywhere by just typing the numbers to each other (no cheating and defining number literals as functions ;) ). -- Mateusz K. ___ 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] Hoogle vs Hayoo
Hi, Hoogle is definitely not deprecated. The reason you can't yet search all packages simultaneously is that it consumes too many resources - the number of Haskell packages exploded at a time when I wasn't able to spend enough time to allow Hoogle to keep up. It's definitely something on the todo list! The FP complete guys are helping with the work required to get there. Be careful what you wish for though. I can't almost guarantee that every type you search for is available in the lens package as a hylo-zygote-para-poly-morphism if you instantiate the Bazaar applicative to the right type. I agree that sorting the platform packages to the top of the list is likely to help make this more manageable. Thanks, Neil On Fri, Aug 23, 2013 at 3:53 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: On 23/08/13 14:57, jabolo...@google.com wrote: It's a bit pointless, if I have to know the package, where I want to search in. Yeah! It does sound a bit pointless. Hoogle should search everything by default, and then you can refine your search by clicking on the '+' or '-' on the packages that appear on the left menu. Jose +1 to this, I never even knew this functionality existed. Why not have a checkbox or something along these lines to enable the search in all packages? This wouldn't change the old behaviour by default and it would allow for a wider search. -- Mateusz K. ___ 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] Performance of delete-and-return-last-element
Am 31.08.13 14:35, schrieb Petr Pudlák:
One solution would be to fold over a specific semigroup instead of a
recursive function:
|import Data.Semigroup
import Data.Foldable(foldMap)
import Data.Maybe(maybeToList)
data Darle a =Darle {getInit :: [a],getLast ::a }
deriving Show
instance Semigroup (Darle a)where
~(Darle xs1 l1) ~(Darle xs2 l2) =Darle (xs1 ++ [l1] ++ xs2) l2
darle :: [a] -Darle a
darle = foldr1 () . map (Darle [])|
It's somewhat more verbose, but the core idea is clearly expressed in
the one line that defines ||, and IMHO it better shows /what/ are we
doing rather than /how/. It's sufficiently lazy so that you can do
something like |head . getInit $ darle [1..]|.
I am wondering why you put the Semigroup instance there and what the
other imports are for. Doesn't this work just as well?
data Darle a = Darle {getInit :: [a], getLast :: a}
deriving Show
~(Darle xs1 l1) ~(Darle xs2 l2) = Darle (xs1 ++ [l1] ++ xs2) l2
darle :: [a] -Darle a
darle = foldr1 () . map (Darle [])
Seems to work here. I am still puzzled, though, if this is really a good
idea performance-wise. I am afraid I don't understand it well enough.
Harald
--
Harald Bögeholzb...@ct.de (PGP key available from servers)
Redaktion c't Tel.: +49 511 5352-300 Fax: +49 511 5352-417
http://www.ct.de/
int f[9814],b,c=9814,g,i;long a=1e4,d,e,h;
main(){for(;b=c,c-=14;i=printf(%04d,e+d/a),e=d%a)
while(g=--b*2)d=h*b+a*(i?f[b]:a/5),h=d/--g,f[b]=d%g;}
(Arndt/Haenel)
Affe Apfel Vergaser
/* Heise Zeitschriften Verlag GmbH Co. KG * Karl-Wiechert-Allee 10 *
30625 Hannover * Registergericht: Amtsgericht Hannover HRA 26709 *
Persönlich haftende Gesellschafterin: Heise Zeitschriften Verlag *
Geschäftsführung GmbH * Registergericht: Amtsgericht Hannover, HRB
60405 * Geschäftsführer: Ansgar Heise, Dr. Alfons Schräder */
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiler stops at SpecConstr optimization
Yes, that GHC ticket shows that this problem is well known. Thank you. On Fri, Aug 30, 2013 at 2:19 AM, Ben Lippmeier b...@ouroborus.net wrote: On 30/08/2013, at 2:38 AM, Daniel Díaz Casanueva wrote: While hacking in one of my projects, one of my modules stopped to compile for apparently no reason. The compiler just freezes (like if it where in an infinite loop) while trying to compile that particular module. Since I had this problem I have been trying to reduce the problem as much as I could, and I came out with this small piece of code: module Blah (foo) where import Data.Vector (Vector) import qualified Data.Vector as V foo :: (a - a) - Vector a - Vector a foo f = V.fromList . V.foldl (\xs x - f x : xs) [] Probably an instance of this one: http://ghc.haskell.org/trac/ghc/ticket/5550 Ben. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On Markdown in Haddock and why it's not going to happen
On 01/09/13 13:59, Niklas Hambüchen wrote: On 01/09/13 04:27, Mateusz Kowalczyk wrote: It doesn't have to be 1-to-1 but the features have to be expressible in both: it's useless if we have different features with one syntax but not the other. I don't find that useless. Markdown does not have definition lists, but we use a normal list to achieve the same documentation goals. Already being able to simply write basic markdown would bring me big practical benefits, and I would prefer minor theoretical misalignments not to outweigh them. I haven't considered it this way before. I'll try to implement it today as an experiment and hopefully show-off the result so we can see whether it's worth using. -- Mateusz K. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: Polymorphic typeclass and Records
Thanks! You do a great job! Adam Gundry wrote Haskell doesn't allow classes to be polymorphic in the names of their methods Yes, still not (( -- View this message in context: http://haskell.1045720.n5.nabble.com/Proposal-Polymorphic-typeclass-and-Records-tp5735096p5735365.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] Proposal: Generic conditions for 'if' and 'case'
I think it is an old idea, but nevertheless. Now we have next functions: if (a :: Bool) then x else y case b of a1 :: Bool - x1 a2 :: Bool - x2 ... Let we have generic conditions for 'if' and 'case': class Boolean a where toBool :: a - Bool instance Boolean Bool where toBool = id instance Boolean [a] where toBool [] = False toBool _ = True instance Boolean (Maybe a) where toBool Nothing = False toBool _ = True instance Boolean Int where toBool 0 = False toBool _ = True if' (a :: Boolean b) then x else y case' d of a1 :: Boolean b1 - x1 a2 :: Boolean b2 - x2 ... It is very easy to implement to desugar: if' a then ... == if toBool ( a ) then ... -- View this message in context: http://haskell.1045720.n5.nabble.com/Proposal-Generic-conditions-for-if-and-case-tp5735366.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
Re: [Haskell-cafe] Proposal: Generic conditions for 'if' and 'case'
I didn't test it, but you might want to look into the 'rebindable syntax' extension and its 'ifThenElse' feature. Nicolas On Sep 2, 2013 12:51 AM, Wvv vite...@rambler.ru wrote: I think it is an old idea, but nevertheless. Now we have next functions: if (a :: Bool) then x else y case b of a1 :: Bool - x1 a2 :: Bool - x2 ... Let we have generic conditions for 'if' and 'case': class Boolean a where toBool :: a - Bool instance Boolean Bool where toBool = id instance Boolean [a] where toBool [] = False toBool _ = True instance Boolean (Maybe a) where toBool Nothing = False toBool _ = True instance Boolean Int where toBool 0 = False toBool _ = True if' (a :: Boolean b) then x else y case' d of a1 :: Boolean b1 - x1 a2 :: Boolean b2 - x2 ... It is very easy to implement to desugar: if' a then ... == if toBool ( a ) then ... -- View this message in context: http://haskell.1045720.n5.nabble.com/Proposal-Generic-conditions-for-if-and-case-tp5735366.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] function arithmetic?
On 1/09/2013, at 7:06 PM, Christopher Howard wrote: It seemed to be suggesting that a Num instance for functions would imply the need for constant number functions, which leads to difficulties. But I don't see why one would have to take it that far. You *cannot* make a type an instance of Num without saying how to map integer literals to that type. If you want (f+g)x = fx + gx then having 2x = 2 makes perfect sense, because then (f+2)x = fx + 2 just as an APL or S programmer would expect. The fact that 2(x+y) will then evaluate to 2 without evaluating x or y is unfortunate, but inevitable. I'm sure I could live with it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can I use String without in ghci?
On 1/09/2013, at 6:02 PM, yi lu wrote: I want to know if it is possible that I use strings without . If I type Preludefoo bar which actually I mean Preludefoo bar However I don't want to type s. I have noticed if bar is predefined or it is a number, it can be used as arguments. But can other strings be used this way? If bar is predefined, it *isn't* the string 'b':'a':'r':[]. If bar is a number, it *isn't* a string. So other strings is quite misleading. In Haskell, if you use strings a lot, you are probably doing something wrong. For things that are not text manipulation tasks, there is practically always a better type, and these days, for things that _are_ text manipulation, there is practically always a better type. A slogan I have programmed by since I first met C and recognised how vastly superior to PL/I it was for text manipulation _because_ it didn't have a proper string type is Strings are Wrong!. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: th-desugar simplifies Template Haskell processing
No, but I agree that this behavior is useful and in the spirit of th-desugar. I can add this to the next version, which should come out in a few days (tomorrow?), because I've noticed a bug with the scoping of as-patterns in let statements. Thanks for the suggestion! Richard On Aug 31, 2013, at 12:06 PM, Sjoerd Visscher wrote: Great package! One question: Do you remove/inline type synonyms? I ask because I just ran into this with some TH code. I'm looking for types that end with - a, but that fails when type synonyms are involved. Sjoerd On Aug 30, 2013, at 2:08 AM, Richard Eisenberg e...@cis.upenn.edu wrote: I've just uploaded my new th-desugar package, which enables easier processing of Template Haskell source syntax by desugaring it into a much simpler core language. The meaning of the code after desugaring is identical to before desugaring, but the syntax is much simpler. To wit, th-desugar simplifies out all of the following constructs: - guarded expressions in both functions and case statements - where declarations - do syntax - list/monad comprehensions - record creation / updates - as patterns - non-trivial patterns in a lambda expression - lambda-case - multi-way if - several more If you are writing a library that manipulates Template Haskell syntax, you may wish to consider if th-desugar will make your job easier by forcing you to consider fewer cases. The one source Haskell construct supported by Template Haskell but not supported by th-desguar is view patterns, mostly because these interact quite non-trivially with pattern binders. It's possible this hole will be closed in a future version. Enjoy! Richard ___ 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] Can I use String without in ghci?
On Mon, Sep 2, 2013 at 5:43 AM, Richard A. O'Keefe wrote: A slogan I have programmed by since I first met C and recognised how vastly superior to PL/I it was for text manipulation _because_ it didn't have a proper string type is Strings are Wrong!. I wonder if you notice the irony in your use of 'C' as exemplar in this context? C rode to fame on the back of Unix. And Unix's innovation - one of many - is that at the OS level the string type was made common fare - a universal type. So everything from file names to file contents to IPC is a string. Of course when instructing a beginning programmer your basic premise 'Strings are Wrong!' is most likely right. However if programs are seen as entities interacting with an 'external' world, the currency at the portals is invariably string. And more than just noob programmers have got this wrong - think of the precious one-byte opcodes that Intel wastes on ascii and decimal arithmetic. So while this is true: If bar is predefined, it *isn't* the string 'b':'a':'r':[]. If bar is a number, it *isn't* a string. So other strings is quite misleading. in the innards of haskell, bar is a string On Sun, Sep 1, 2013 at 9:51 PM, Albert Y. C. Lai wrote: When 3 and 1/2 are typed next to each other, i.e., 3 1/2 it is addition. Well mathematicians are always eliding! In 3 1/2 the elision amounts to + In xy it amounts to * And within 23 ie between the 2 and the 3, it amounts to λ x y - 10*x + y And Haskell elides function application When teaching gofer (in the early 90s) I found that undoing the elision of function application and making it explicit, made FP more withing reach of the kids. Idea inspired by Dijkstra http://www.the-magus.in/Publications/ewd.pdf And more recently summarized http://blog.languager.org/2013/08/applying-si-on-sicp.html Rusi -- http://www.the-magus.in http://blog.languager.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can I use String without in ghci?
On 2/09/2013, at 3:55 PM, Rustom Mody wrote: On Mon, Sep 2, 2013 at 5:43 AM, Richard A. O'Keefe wrote: A slogan I have programmed by since I first met C and recognised how vastly superior to PL/I it was for text manipulation _because_ it didn't have a proper string type is Strings are Wrong!. I wonder if you notice the irony in your use of 'C' as exemplar in this context? In all seriousness, a text editor application written in C was *an order of magnitude* smaller in C than in PL/I *because* of the lack of a string data type. C rode to fame on the back of Unix. And Unix's innovation – one of many – is that at the OS level the string type was made common fare – a universal type. So everything from file names to file contents to IPC is a string. The idea of file names being strings was no innovation. Yes, in crippled monstrosities like TOPS-10 file names were weird records -- I can still remember too much of the details -- and every ruddy TOPS-10 program had to do its own file name parsing and it seemed as if they all did it differently. But the B6700 MCP interfaces treated file names as strings before UNIX was dreamed of. File contents in UNIX are *not* strings and never have been -- NUL termination is no part of files and binary files have been commonplace since the beginning (an a.out file is not a string!). They are *byte arrays*. As for IPC, since when have System V shared memory, semaphores, or message queues had anything to do with strings? (Hint: the 'name' of a System V shared memory segment is a key_t, and that's an integral type, not a string. Hint: the 'name' of a System V semaphore is also a key_t integer, not a string. Hint: the 'name' of a System V message queue is also a key_t integer, not a string. Hint: messages sent using msgsnd are not strings, they are byte arrays with a separate count parameter. ) Classic UNIX uses strings for file names, and really, that's it. (The command line argv[] is not really an exception, because it was used for file names as well as options, and in fact mixing the two up caused endless problems.) Everything else in V7, S3, or SysV was identified by a *number*. Plan 9 has exit(string) but Unix has exit(byte). From the perspective of someone who used UNIX v6 in 1979, *POSIX* IPC -- with its IPC objects *might* be in the file system but then again might *not* be so their names are sorta-kinda-like file names but not really) -- and /proc are recent innovations. The idea that 'string' was even remotely like a universal type in UNIX is bizarre. Heck, UNIX never even used 'string' for *lines* in text files! Of course when instructing a beginning programmer your basic premise 'Strings are Wrong!' is most likely right. No, I'm talking about experienced programmers writing high performance programs. However if programs are seen as entities interacting with an 'external' world, the currency at the portals is invariably string. - The currency at the portals is *not* invariably string. Learn PowerShell. - Text is one thing and string is another. This was the B6700 lesson (well, really the B5500 lesson): for many purposes you want a text *stream* not a text *string* at the interface. It's also the what-Smalltalk-got-right-and-Java-got-wrong lesson: the right way to convert objects to text is via a *stream* interface, not a *string* interface. And more than just noob programmers have got this wrong – think of the precious one-byte opcodes that Intel wastes on ascii and decimal arithmetic. Hang on, they are there in order to *support* the numbers are text model. You can't have it both ways. So while this is true: If bar is predefined, it *isn't* the string 'b':'a':'r':[]. If bar is a number, it *isn't* a string. So other strings is quite misleading. in the innards of haskell, bar is a string No, in the innards of Haskell, bar is possibly a number, possibly a pointer to some sort of record, possibly some other data structure, but almost certainly *not* a string. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
