tag:blogger.com,1999:blog-7094652.post4754798348550396197..comments2024-03-23T14:36:09.980+00:00Comments on Neil Mitchell's Blog (Haskell etc): Does Haskell need macros?Neil Mitchellhttp://www.blogger.com/profile/13084722756124486154noreply@blogger.comBlogger15125tag:blogger.com,1999:blog-7094652.post-87005505000755572102017-11-08T16:56:23.668+00:002017-11-08T16:56:23.668+00:00The do expression in Haskell is already a macro, w...The do expression in Haskell is already a macro, which expands into nesting >>= calls Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7094652.post-81572485751437581022011-01-07T12:08:16.419+00:002011-01-07T12:08:16.419+00:00> pi is a function (a constant arity function, ...> pi is a function (a constant arity function, but still a function)<br /><br />No, it’s not.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7094652.post-48361380651518364292009-08-07T18:35:24.328+01:002009-08-07T18:35:24.328+01:00This comment has been removed by the author.Patrick Mahoneyhttps://www.blogger.com/profile/09539069669265570011noreply@blogger.comtag:blogger.com,1999:blog-7094652.post-61617102119021542762009-03-09T18:29:00.000+00:002009-03-09T18:29:00.000+00:00Wouldn't Haskell have macro's automatically if eve...Wouldn't Haskell have macro's automatically if <I>everything</I> was first class including types and Haskell programs? <BR/>Then a macro would be able to accept a Haskell program, parse it, replace the types and functions, and return a new program.<BR/>There doesn't seem to me to be anything mathematically ambiguous about this. Certainly its use cases seem limited, but...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7094652.post-43209622131707879842008-04-08T21:59:00.000+01:002008-04-08T21:59:00.000+01:00Omar: I would consider template Haskell to be a ma...Omar: I would consider template Haskell to be a macro system for Haskell - and all I said about macros still applies to Template Haskell to some degree.Neil Mitchellhttps://www.blogger.com/profile/13084722756124486154noreply@blogger.comtag:blogger.com,1999:blog-7094652.post-32444282425101773062008-04-08T21:52:00.000+01:002008-04-08T21:52:00.000+01:00Just chiming in to say I also wonder why you don't...Just chiming in to say I also wonder why you don't consider Template Haskell to be a (slightly awkward) macro system for Haskell.Omarhttps://www.blogger.com/profile/06206510761450721045noreply@blogger.comtag:blogger.com,1999:blog-7094652.post-85680891632755455272007-04-14T02:21:00.000+01:002007-04-14T02:21:00.000+01:00I tried to write a GNU Make replacement in Haskell...I tried to write a GNU Make replacement in Haskell. One place I really missed lisp (or scheme) macros, is when I had to use two statements in order to a get a build rule in the system: one statement to declare the rule (build this target when its dependencies are out of date, with this command) and another one to register the rule in the rules database. <A HREF="http://ashish.typepad.com/ashishs_niti/2007/03/learning_haskel.html" REL="nofollow"> See the post for details </A>.<BR/>The conjure system, written in scheme48, uses the syntax-rules to automatically register the goal and its rules when they are declared.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7094652.post-92008244900159289352007-01-14T14:36:00.000+00:002007-01-14T14:36:00.000+00:00anon: I think compile time evaluation is very impo...anon: I think compile time evaluation is very important, but optimising lazy compilers already do absolutely loads of this already. I just don't think the user should have to decide what's a compile time thingy, and whats a runtime thingy.Neil Mitchellhttps://www.blogger.com/profile/13084722756124486154noreply@blogger.comtag:blogger.com,1999:blog-7094652.post-42165173792932943942007-01-07T21:54:00.000+00:002007-01-07T21:54:00.000+00:00Neil, I am curious why you think compile time eval...Neil, I am curious why you think compile time evaluation isn't important? I am interested in building a language that generates haskell code, and what better way than to use something like template-haskell?<br /><br />Maybe I'm misunderstanding something, but how could I be sure that all the primitives that I build on top of haskell won't just be interpreted at runtime? (previously I was considering using parsec, but I don't want an interpreter, and I don't want to create intermediate haskell files unnecessarily.<br /><br />I'll admit when I was using scheme, most of what I used macros for were to make a dsl that had a primitive for defining functions that had normal order evaluation, and a few alternate forms like case and a few others.<br /><br />Lawrence, I agree with most of what you are saying, but where I disagree is that I think that lazy evaluation does reduce uses of macros -- at least in my experience, anyway. The reason why I say this is because this is almost exclusively what I use them for in scheme and emacs-lisp, so I think that they would potentially be an asset even for the syntactially-rich python, (or your language converge, but since you're already supporting compile-time metaprogramming so it's not an issue) for that reason alone.<br /><br />In general: (not to anyone specific)<br /><br />I think that if I were not using haskell, a special form that I made in scheme (scsh actually), called sudo (a specific synactic sugar for delaying an expression until the user put in their password) would be still a viable use of macros that wouldn't be in the case of lazy evaluation. Now I know things like that sound cheesy, but I like to add domain specific features of that nature. (and of course that would be effortless in haskell)<br /><br />Other than that, in a language with a minimalist syntax I was also interested in adding an optional whitespace syntax to scheme, but of course both python or haskell already have that...<br /><br />Interesting thoughts, anyhow.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7094652.post-51360004658662929712007-01-05T16:06:00.000+00:002007-01-05T16:06:00.000+00:00There are type synonyms, which may actually let yo...<i>There are type synonyms, which may actually let you do the above trick with GADT's (I haven't tried, but its certainly feasible they could work like that, even if they currently don't).</i><br /><br />That's what macros are for, right? Trying stuff out that's not currently supported.<br /><br /><i>For truly repetitive tasks, Template Haskell can be used, or things like Drift </i><br /><br />It might help if you can tell us why you don't consider TH a macro system.<br /><br />It might also help to specify what types of macros we're talking about. Common Lisp has a whole host of different macro types, including...<br /><br />* <a href="http://www.lisp.org/HyperSpec/Body/mac_defmacro.html">defmacro</a><br />* <a href="http://www.lisp.org/HyperSpec/Body/fun_set-macro_ro-character.html#set-macro-character">Reader macros</a> <br />* <a href="http://www.lisp.org/HyperSpec/Body/mac_define-compiler-macro.html">compiler macros</a> <br />* <a href="http://www.lisp.org/HyperSpec/Body/speope_symbol-macrolet.html">symbol macros</a> <br /><br />Besides the <a href="http://hackage.haskell.org/trac/haskell-prime/wiki/HaskellExtensions">obvious list</a> of things that might become possible with macros, here's a few more off the top of my head...<br /><br />* <a href="http://www.cs.yale.edu/homes/tullsen/patterns.ps">First class patterns</a><br />* Views<br />* <a href="http://lambda-the-ultimate.org/node/1453">Open data types</a><br />* <a href="http://www.cs.chalmers.se/~d00nibro/harp/">HaRP</a><br />* DriFT<br />* All those <a href="http://www.md.chalmers.se/~patrikj/poly/polyp/">polytypic</a> <a href="http://www.generic-haskell.org/">generic</a> <a href="http://www.informatik.uni-bonn.de/~ralf/publications/NOW.pdf">Haskell</a> derivatives<br />* <a href="http://partial-eval.org/">Partial evaluation</a>/compile time evaluation/<a href="http://okmij.org/ftp/Computation/Generative.html#for-HPC-generator">multi-stage programming</a><br />* optional and keyword arguments<br />* postfix, new mixfix operators (like "do" notation, if-then-else, etc.)<br />* Literal syntax for arrays, sets, hexadecimal/binary numbers, etc.<br />* better syntax for DSLs (regexes, parsec, etc.)<br />* Type system extentions (linear/unique types, associated types, etc.)<br /><br />Sure, you can <a href="http://citeseer.ist.psu.edu/mcbride01faking.html">fake</a> some of that stuff, but why not try to make it nice/easy to use?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7094652.post-27349607271621184212007-01-05T12:41:00.000+00:002007-01-05T12:41:00.000+00:00one reason haskell "needs" macros is that it's an ...one reason haskell "needs" macros is that it's an interesting area of design space. macros / staged evaluation in a lazy, typed system sounds like an intersting problem. this is the "fly to the moon" argument - there may not be a simple practical case, but who knows what we might learn on the way?Unknownhttps://www.blogger.com/profile/11760508644619954982noreply@blogger.comtag:blogger.com,1999:blog-7094652.post-43021203747228482412007-01-05T11:52:00.000+00:002007-01-05T11:52:00.000+00:00Dan: My argument is more that you don't need macro...Dan: My argument is more that you don't need macros in a lazy language - the typed/untyped thing is less of an issue.<br /><br />Conor: Yes, I remember your Haskell' proposal (I think it was), but was too lazy to find a link when I was writing this :)Neil Mitchellhttps://www.blogger.com/profile/13084722756124486154noreply@blogger.comtag:blogger.com,1999:blog-7094652.post-9689408434340024652007-01-05T11:26:00.000+00:002007-01-05T11:26:00.000+00:00For the record, I'm on the record proposing "Patte...For the record, I'm on the record proposing "Pattern Synonyms" (certainly not general untyped macros), precisely to cut down clutter on the LHS of functions. I have lots of examples where this would be useful. There are lots of abstractions which Haskell doesn't support, or supports very clumsily (mutter mutter type class hackery). Macros are a bad solution to a failure of abstraction. But a good solution might still be desirable.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7094652.post-23850328692941683112007-01-05T10:25:00.000+00:002007-01-05T10:25:00.000+00:00Look at MetaML and MacroML. The thing missing from...Look at MetaML and MacroML. The thing missing from Lisp macros that Haskell would need is type safety and Multi-Stage Programming seems the best way so far of doing it.<br /><br />It's seems very similar to Template Haskell (sans AST manipulation).<br /><br />Being able to define do notation as a type-safe macro in a library should be enough of a boon. Of course MSP would also allow type safe compilation of a DSL to Haskell at run-time, which is more than a little cool. Partial evaluation is also closely related.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7094652.post-61266272892987421692007-01-05T05:16:00.000+00:002007-01-05T05:16:00.000+00:00Someone asked this already on reddit, to witch I h...Someone asked this already on reddit, to witch I had written a long post (don't know where it is)<br /><br /><br />But, the short of it is macros are only useful in untyped languages like lisp.Since haskell is statically typed, you may as well just write the actual code due to the implicit constraints already on your functionsUnknownhttps://www.blogger.com/profile/14226017592661481466noreply@blogger.com