Re: [Haskell-cafe] Exploring Programming Language Theory
If you want compiling functional languages and can relax the requirement for up to date: Antoni Diller's Compiling Functional Languages is good. It is short enough (300 pages) that you could reasonably work through it and it includes the full source of a compiler in the appendix - written in Pascal so translating it to something else is a sufficient exercise. It is long out of print, but copies turn up on Amazon - I got it from Amazon UK for a couple of pounds. Also Franklyn Turbak and David Gifford's Design Concepts for Programming Languages is very good (and new!) but huge. It is not quite exhaustive - as a skim reader I wanted the specification / translation rules for a particular compile step and frustratingly it was left as an exercise. Otherwise it is a very good presentation - it uses translation rules (ala the LaTeX Semantic package) rather than source code throughout, so once you are used to the style it is both very concise (and precise) and unlikely to go out of date any time soon. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] mtl: Why there is Monoid w constraint in the definition of class MonadWriter?
* Edward Z. Yang ezy...@mit.edu [2012-12-08 15:45:54-0800] Second, even *if* the above holds (two tells are equivalent to one tell), then there is *some* function f such that tell w1 tell w2 == tell (f w1 w2) It isn't necessary that f coincides with mappend, or even that the type w is declared as a Monoid at all. The only thing we can tell from the Monad laws is that that function f should be associative. Well, the function is associative: that's half of the way there to a monoid; all you need is the identity! But we have those too: whatever the value of the execWriter (return ()) is... Let me repeat: It isn't necessary that f coincides with mappend, or even that the type w is declared as a Monoid at all. Let me illustrate this with an example. data MyWriter a = MyWriter Integer a instance Monad MyWriter where return = MyWriter 0 MyWriter n x = k = let MyWriter n' y = k x in MyWriter (n+n') y instance MonadWriter Integer MyWriter where tell n = MyWriter n () listen (MyWriter n x) = return (x,n) pass (MyWriter n (a,f)) = MyWriter (f n) a Yes, integers do form a monoid when equipped with 0 and (+). However, we know well why they are not an instance of Monoid — namely, there's more than one way they form a monoid. Even if something is in theory a monoid, there may be technical reasons not to declare it a Monoid. Likewise, imposing a (technical) superclass constraint on MonadWriter has nothing to do with whether the Monad will be well-behaved. This is true in both directions: even if the type is an instance of Monoid, nothing forces the Monad instance to use the Monoid instance. I.e. I can declare a MonadWriter on the Sum newtype whose bind, instead of adding, subtracts the numbers. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How can I avoid buffered reads?
On Thu, Dec 6, 2012 at 5:23 PM, Brandon Allbery allber...@gmail.com wro\ Both should be cdevs, not files, so they do not go through the normal filesystem I/O pathway in the kernel and should support select()/poll(). (ls -l, the first character should be c instead of - indicating character-mode device nodes.) If ghc is not detecting that, then *that* is indeed an I/O manager issue. The issue here is that if you look at the source of fdReadBuf, you see that it's a plain system call without any reference to GHC's (relatively new) IO manager. Best, Leon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] mtl: Why there is Monoid w constraint in the definition of class MonadWriter?
Hi all, I'd say that a type class declares functions and specifies laws (in the docs) what its implementations must adhere to. It's not the job of a type class to fulfill the laws, it's the job of its implementations. So the reason for 'Monoid w' in 'MonadWriter' cannot be that then 'MonadWriter' wouldn't be a monad. Such constraints should be required only by implementations. It is true that any Writer has an implicit underlying monoid, and we can even extract the operations from it as follows. The empty element can be extracted as empty = liftM snd (listen (return ())) :: m w Having this 'empty', we can give 'const empty' to 'pass' to discard output of an action, so we can construct: -- | @contained m@ executes the action @m@ in a contained environment and -- returns its value and its output. The current output is not modified. contained :: m a - m (a, w) contained k = do -- we can retrieve mempty even if we don't have the monoid constraint: ~(_, empty) - listen (return ()) -- listen what @k@ does, get its result and ignore its output change: pass (listen k = \x - return (x, const empty)) This generalizes 'listen' and 'pass' (both can be easily defined from it) and I find this function much easier to understand. In a way, it is also a generalization of WriterT's runWriterT, because for WriterT we have 'contained = lift . runWriterT'. [I implemented 'contained' in a fork of the mtl library, if anybody is interested: https://github.com/ppetr/mtl ] With that, we can do -- Doesn't produce any output, only returns the combination -- of the arguments. append x y = liftM snd $ contained (tell x tell y) :: w - w - m w I didn't check the monoid laws, but it seems obvious that they follow from the monad laws and (a bit vague) specification of 'listen' and 'pass'. Personally, I'd find it better if `MonadWriter` would be split into two levels: One with just 'tell' and 'writer' and the next level extending it with 'listen'/'pass'/'contained'. The first level would allow things like logging to a file, without any monoidal structure. But this would break a lot of stuff (until we agree on and develop something like http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances). Best regards, Petr 2012/12/9 Roman Cheplyaka r...@ro-che.info * Edward Z. Yang ezy...@mit.edu [2012-12-08 15:45:54-0800] Second, even *if* the above holds (two tells are equivalent to one tell), then there is *some* function f such that tell w1 tell w2 == tell (f w1 w2) It isn't necessary that f coincides with mappend, or even that the type w is declared as a Monoid at all. The only thing we can tell from the Monad laws is that that function f should be associative. Well, the function is associative: that's half of the way there to a monoid; all you need is the identity! But we have those too: whatever the value of the execWriter (return ()) is... Let me repeat: It isn't necessary that f coincides with mappend, or even that the type w is declared as a Monoid at all. Let me illustrate this with an example. data MyWriter a = MyWriter Integer a instance Monad MyWriter where return = MyWriter 0 MyWriter n x = k = let MyWriter n' y = k x in MyWriter (n+n') y instance MonadWriter Integer MyWriter where tell n = MyWriter n () listen (MyWriter n x) = return (x,n) pass (MyWriter n (a,f)) = MyWriter (f n) a Yes, integers do form a monoid when equipped with 0 and (+). However, we know well why they are not an instance of Monoid — namely, there's more than one way they form a monoid. Even if something is in theory a monoid, there may be technical reasons not to declare it a Monoid. Likewise, imposing a (technical) superclass constraint on MonadWriter has nothing to do with whether the Monad will be well-behaved. This is true in both directions: even if the type is an instance of Monoid, nothing forces the Monad instance to use the Monoid instance. I.e. I can declare a MonadWriter on the Sum newtype whose bind, instead of adding, subtracts the numbers. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Exploring Programming Language Theory
Stephen Tetley stephen.tetley at gmail.com writes: Also Franklyn Turbak and David Gifford's Design Concepts for Programming Languages is very good (and new!) but huge. Yes! I like that book very much, and I use it for teaching semantics and compilation of programming languages. Semantics - by writing interpreters, in several domains. The book avoids the M word, but of course it is actually the Identity monad, the State monad, the CPS monad etc. (I guess it should really be presented via monad transformers, though.) J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] education or experience?
Christopher Howard wrote: I'm at something of a crossroads, and I'm hoping to get a bit of free career advice. I really enjoy programming with Haskell (and a few other exotic languages), and was hoping I could eventually make a living in that sort of field. Not rich and famous, necessarily, just enough to get by comfortably. I'm trying to decide, however; should I go back to school, finish my B.S. and pursue a Masters in CompSci? Or would the time (and money) be better spent aggressively pursuing volunteer work for companies, hoping to eventually get the experience and contacts that lead to a paying job? To be honest, I don't really want to go back to school, because I learn a lot faster (and more economically) on my own. However, I'm not sure which path is the fastest, and safest, approach to an actual paycheck. Concerning a university education, there are two approaches: 1. I want to learn as much as possible 2. I want to learn just enough to get a high-paying job University is great at serving the first approach, not only because you have the freedom to skip lectures that you already know, but also because professors have a lot of interesting things to teach if you let them, and because some of your classmates will be equally interested and interesting. In other words, if you want to learn everything, then university is the right environment. On the other hand, approaching university from the second point of view usually does not justify the cost for the little benefit you obtain this way. Unfortunately, it seems to me that the tuition costs in the U.S. strongly suggest the second approach. To avoid this, I recommend to either go abroad or become very good and acquire a scholarship. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] education or experience?
Yes... CS academics delivers less than it could/should; and whatever this delivery is, its asymptotically sub-linear. Some of it is to do with the not-quick-enough takeup of FP in academia, though there are obviously many other factors as well. http://blog.languager.org/2011/02/cs-education-is-fat-and-weak-1.html and sequel is about this: how we are not getting over the quirks of the past history of CS in present day teaching. Here too suggestions for modifications/ change of emphasis are appreciated. Rusi's cogent blog post includes a list of techniques/concepts that the unconverted could profitably pick up from the FP community. In fact the FP community came late to some of these, just as programming languages at large came late to garbage collection. Lazy evaluation--at the heart of spreadsheets since the beginning. Pattern matching--native to string processing (e.g. COMIT, SNOBOL). Appeared nearly in its present form in COGENT (1965). Booleans as first class*--surely this is a joke. Algol 60 had them. Matlab exploits them heavily (though represented as doubles). Data orientation--COBOL fostered this outlook; see Michael Jackson. As long as Lisp ruled, FP lagged on data types. FP also deserves credit for infinite data structures (though the special case of stream processing dates way back). Doug McIlroy * It's amusing to note that real Booleans--the ones that Boole used--were integers. For Boole, or(a,b) = a + b - a*b. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] education or experience?
Thanks Doug for reminding me of points that I had forgotten (and which are new) I will insert them into the blog My comments inline On Sun, Dec 9, 2012 at 10:01 PM, Doug McIlroy d...@cs.dartmouth.edu wrote: Yes... CS academics delivers less than it could/should; and whatever this delivery is, its asymptotically sub-linear. Some of it is to do with the not-quick-enough takeup of FP in academia, though there are obviously many other factors as well. http://blog.languager.org/2011/02/cs-education-is-fat-and-weak-1.html and sequel is about this: how we are not getting over the quirks of the past history of CS in present day teaching. Here too suggestions for modifications/ change of emphasis are appreciated. Rusi's cogent blog post includes a list of techniques/concepts that the unconverted could profitably pick up from the FP community. In fact the FP community came late to some of these, just as programming languages at large came late to garbage collection. Lazy evaluation--at the heart of spreadsheets since the beginning. Never thought of that -- nice! Pattern matching--native to string processing (e.g. COMIT, SNOBOL). Snobol -- yes, comit Ive heard of but dont know Appeared nearly in its present form in COGENT (1965). Hmm google gives me different cogents/ I guess you are referring to the Reynolds one? Booleans as first class*--surely this is a joke. Algol 60 had them. Not sure what you are saying (unless its about the footnote that Boole treated bools as ints! This is new to me) I was referring to the fact that C programmers have great difficulty thinking of bools as first class for similar reasons to why lists as first class is hard. [And python programmers also for that matter, whose language does not have a proper first class bool type] Matlab exploits them heavily (though represented as doubles). Not sure what you are referring to Data orientation--COBOL fostered this outlook; see Michael Jackson. Interesting! I wonder though whether you and I use 'data-orientation' in the same way? See below. As long as Lisp ruled, FP lagged on data types. A tendentious point: A lisper would say that since Lisp from the beginning had a universal data-type, it need never bother to restrict types. [Note I recollect first hearing the term data orientation from SICP] FP also deserves credit for infinite data structures (though the special case of stream processing dates way back). Doug McIlroy * It's amusing to note that real Booleans--the ones that Boole used--were integers. For Boole, or(a,b) = a + b - a*b. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- 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] education or experience?
On Sun, Dec 9, 2012 at 11:04 PM, Malcolm Wallace malcolm.wall...@me.comwrote: On 9 Dec 2012, at 16:31, Doug McIlroy wrote: In fact the FP community came late to some of these, just as programming languages at large came late to garbage collection. Lazy evaluation--at the heart of spreadsheets since the beginning. Lazy evaluation for the lambda calculus - 1971 (Wadsworth) Lazy evaluation in a programming language - 1976 (HendersonMorris, FriedmanWise) I wouldn't call those dates late, especially since VisiCalc, the first widely-used electronic spreadsheet entered the market in 1978. Regards, Malcolm You are reading an associativity/parse to Doug's post that he probably did not intend. FP came late was meant to apply to the data orientation (I think) thanks to the long domination of Lisp ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] mtl: Why there is Monoid w constraint in the definition of class MonadWriter?
An additional thought: I'd say 'contained' is sort of inverse to 'writer': writer = contained = id contained . writer = return Petr Pudlak 2012/12/9 Petr P petr@gmail.com Hi all, I'd say that a type class declares functions and specifies laws (in the docs) what its implementations must adhere to. It's not the job of a type class to fulfill the laws, it's the job of its implementations. So the reason for 'Monoid w' in 'MonadWriter' cannot be that then 'MonadWriter' wouldn't be a monad. Such constraints should be required only by implementations. It is true that any Writer has an implicit underlying monoid, and we can even extract the operations from it as follows. The empty element can be extracted as empty = liftM snd (listen (return ())) :: m w Having this 'empty', we can give 'const empty' to 'pass' to discard output of an action, so we can construct: -- | @contained m@ executes the action @m@ in a contained environment and -- returns its value and its output. The current output is not modified. contained :: m a - m (a, w) contained k = do -- we can retrieve mempty even if we don't have the monoid constraint: ~(_, empty) - listen (return ()) -- listen what @k@ does, get its result and ignore its output change: pass (listen k = \x - return (x, const empty)) This generalizes 'listen' and 'pass' (both can be easily defined from it) and I find this function much easier to understand. In a way, it is also a generalization of WriterT's runWriterT, because for WriterT we have 'contained = lift . runWriterT'. [I implemented 'contained' in a fork of the mtl library, if anybody is interested: https://github.com/ppetr/mtl ] With that, we can do -- Doesn't produce any output, only returns the combination -- of the arguments. append x y = liftM snd $ contained (tell x tell y) :: w - w - m w I didn't check the monoid laws, but it seems obvious that they follow from the monad laws and (a bit vague) specification of 'listen' and 'pass'. Personally, I'd find it better if `MonadWriter` would be split into two levels: One with just 'tell' and 'writer' and the next level extending it with 'listen'/'pass'/'contained'. The first level would allow things like logging to a file, without any monoidal structure. But this would break a lot of stuff (until we agree on and develop something like http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances). Best regards, Petr 2012/12/9 Roman Cheplyaka r...@ro-che.info * Edward Z. Yang ezy...@mit.edu [2012-12-08 15:45:54-0800] Second, even *if* the above holds (two tells are equivalent to one tell), then there is *some* function f such that tell w1 tell w2 == tell (f w1 w2) It isn't necessary that f coincides with mappend, or even that the type w is declared as a Monoid at all. The only thing we can tell from the Monad laws is that that function f should be associative. Well, the function is associative: that's half of the way there to a monoid; all you need is the identity! But we have those too: whatever the value of the execWriter (return ()) is... Let me repeat: It isn't necessary that f coincides with mappend, or even that the type w is declared as a Monoid at all. Let me illustrate this with an example. data MyWriter a = MyWriter Integer a instance Monad MyWriter where return = MyWriter 0 MyWriter n x = k = let MyWriter n' y = k x in MyWriter (n+n') y instance MonadWriter Integer MyWriter where tell n = MyWriter n () listen (MyWriter n x) = return (x,n) pass (MyWriter n (a,f)) = MyWriter (f n) a Yes, integers do form a monoid when equipped with 0 and (+). However, we know well why they are not an instance of Monoid — namely, there's more than one way they form a monoid. Even if something is in theory a monoid, there may be technical reasons not to declare it a Monoid. Likewise, imposing a (technical) superclass constraint on MonadWriter has nothing to do with whether the Monad will be well-behaved. This is true in both directions: even if the type is an instance of Monoid, nothing forces the Monad instance to use the Monoid instance. I.e. I can declare a MonadWriter on the Sum newtype whose bind, instead of adding, subtracts the numbers. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] education or experience?
Heinrich Apfelmus apfel...@quantentunnel.de wrote: Christopher Howard wrote: Concerning a university education, there are two approaches 1. I want to learn as much as possible 2. I want to learn just enough to get a high-paying job There's actually a third approach ( and probably more): 3. I want to learn to do this job as well as possible. On the other hand, approaching university from the second point of view usually does not justify the cost for the little benefit you obtain this way. Unfortunately, it seems to me that the tuition costs in the U.S. strongly suggest the second approach. To avoid this, I recommend to either go abroad or become very good and acquire a scholarship. That really depends on the job at in question. When I was looking for entry level programming jobs, not having a degree meant you never got past the hr department. Getting a degree (pretty much any degree) was required to get the high-paying job. I'm willing to believe that's no longer the case for programmers, because academia has consistently failed to deliver sufficient quality programmers to meet industry needs. On the other hand (watching my sons deal with the job market), the litmus test for you've got what it takes to survive in the system is now a masters, not a bachelors, so maybe you're wrong about that. The other thing to consider is what your long-term goals are. Do you want to be a code monkey all your life? Or do you aspire to more? What are the requirements for that more? Getting a degree now may well avoid doing it later. Finally, with approach #3, you really need a mentor who can tell you whether or not you're doing a competent job. You're much more likely to find that in a university environment than trying to learn things by yourself. Joining an open source project might get it for you. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How can I avoid buffered reads?
On 9 December 2012 10:29, Leon Smith leon.p.sm...@gmail.com wrote: On Thu, Dec 6, 2012 at 5:23 PM, Brandon Allbery allber...@gmail.com wro\ Both should be cdevs, not files, so they do not go through the normal filesystem I/O pathway in the kernel and should support select()/poll(). (ls -l, the first character should be c instead of - indicating character-mode device nodes.) If ghc is not detecting that, then *that* is indeed an I/O manager issue. The issue here is that if you look at the source of fdReadBuf, you see that it's a plain system call without any reference to GHC's (relatively new) IO manager. What if you use threadWaitRead on the fd before you read from it? http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Concurrent.html#v:threadWaitRead Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] education or experience?
Lazy evaluation--at the heart of spreadsheets since the beginning. Never thought of that -- nice! Unfortunately it's not literally true, because spreadsheets push recalculated values to all the variables that depend on them, rather than waiting until the dependent values are needed. But the idea that sequencing is by dependency rather than by algorithmic specification is the same. I remember playing around (before spreadsheets) with the idea for Fortran-like code and concluding that the benefit of not having to specify sequence wasn't worth the effort. What a lack of imagination! Pattern matching--native to string processing (e.g. COMIT, SNOBOL). Appeared nearly in its present form in COGENT (1965). Hmm google gives me different cogents/ I guess you are referring to the Reynolds one? Yes. Booleans as first class*--surely this is a joke. Algol 60 had them. Not sure what you are saying (unless its about the footnote that Boole treated bools as ints! This is new to me) I was referring to the fact that C programmers have great difficulty thinking of bools as first class Your observation is interesting. Booleans and their utility were well known when C was designed. But since the language level was deliberately very close to real machine architecture, which rarely had native support for 1-bit quantities, the data type was deemed superfluous. (If C had begun on the IBM 7030 it probably would have have had Booleans.) I don't remember anybody predicting that the choice risked banishing Booleans from mind. The one deviation from real architecture that C did embrace was to define a representation for the result of comparison. That had another unpredicted consequence: computer architects imitated the language in hardware! (C's largely ignored bitfield capability came later and, if anything, demoted Booleans to an artifact of structs.) The joke I saw was that there was no way that Boolean values had ever been denied first-class citizenship as Strachey defined it--even if they didn't have a special syntactic identity. Matlab exploits them heavily (though represented as doubles). Not sure what you are referring to I had in mind Matlab's frequent use of a Boolean array as a characteristic function describing some property of the elements of another array. Such arrays are used to control other array operations. In this usage, the characteristic array may be optimized out of existense, but it fosters higher-level thinking and concise code. In reply to your second note, Malcolm Wallace is right. I did intend to say that FP was late with lazy evaluation. My mistake was to think VisiCalc had appeared before 1970. Similarly, I believed that call by need came into our vocabulary soon after Algol 60 brought call be name and call by value to our attention as somewhat better-behaved models than Fortran's call by reference. Now I suspect that belief is wrong, too. Doug ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] education or experience?
___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GHCi + FFI + global C variables
I'm currently working with a C library that needs to use/modify global C
variables, for example:
igraph_bool_t igraphhaskell_initialized = 0;
int igraphhaskell_initialize()
{
if (igraphhaskell_initialized != 0)
{
printf(C: Not initializing. igraphhaskell_initialized = %i\n,
igraphhaskell_initialized);
return 1;
}
// initialization
}
If I compile an example programm using this library everything works
fine, but if I try to run the same program in GHCi it dies with the message
C: Not initializing. igraphhaskell_initialized = -90
The value (and apparently the adress of the global variable) is
completly off, and I have no idea what is causing this or how to solve
this issue and make the library GHCi-friendly. Is it possible to run
this code in GHCi at all? Also, since it's a foreign library I obviously
cannot just change the C code to simply not use any global variables at all.
- Nils
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] education or experience?
On 10/12/2012, at 6:34 AM, Malcolm Wallace wrote: On 9 Dec 2012, at 16:31, Doug McIlroy wrote: In fact the FP community came late to some of these, just as programming languages at large came late to garbage collection. Lazy evaluation--at the heart of spreadsheets since the beginning. Lazy evaluation for the lambda calculus - 1971 (Wadsworth) Lazy evaluation in a programming language - 1976 (HendersonMorris, FriedmanWise) Pop-2 had lazily evaluated streams about 1970. In fact that's how it did input: a 'character producer' was nothing other than a lazily evaluated list of characters. The book about it appeared in 1971. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Exploring Programming Language Theory
Try http://lambda-the-ultimate.org/node/492 On Sat, Dec 8, 2012 at 2:41 PM, Danny Gratzer danny.grat...@gmail.comwrote: Sorry for the multiple posts, last time I try to write any decent length email from my phone... Anyways, and that was a tutorial not an introduction. I am also reading his The Implementation of Functional Programming Languages. But in any case, I'm liking these books a lot! It's super interesting and everything but a little out of date. Does anyone know of books that cover a similar subject matter but are more current? To summarize, books that go from compiling a high level language to lambda calculus and/or the theory behind lambda calculus and similar? Thank you so much! On Sat, Dec 8, 2012 at 4:32 PM, Danny Gratzer danny.grat...@gmail.comwrote: Hello, Sorry in advance for the soft question: Recently I have been studying more about how a lazy functional language is designed and compiled and have been reading Peyton-Jones's book implementing functional languages: an introduction -- Danny Gratzer ___ 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] education or experience?
On Mon, Dec 10, 2012 at 5:33 AM, Doug McIlroy d...@cs.dartmouth.edu wrote: Matlab exploits them heavily (though represented as doubles). Not sure what you are referring to I had in mind Matlab's frequent use of a Boolean array as a characteristic function describing some property of the elements of another array. Such arrays are used to control other array operations. In this usage, the characteristic array may be optimized out of existense, but it fosters higher-level thinking and concise code. In which case it goes back to APL's compress operator ie 1960. http://www.aplusdev.org/APlusRefV2_8.html#HEADING179 Heres a session that demonstrates A+ Copyright (c) 1990-2008 Morgan Stanley. All rights reserved. This version is Release 4.22 a ← 1 2 3 4 5 b ← 1 0 1 1 0 b/a 1 3 4 b ← 1 0 2 1 0 b/a 1 3 3 4 -- 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] Fwd: education or experience?
On 12/10/2012 01:20 AM, Eli Frey wrote: Jerzy makes a good point that you might not be the best judge of what you should learn. Not only that: you have *no reliable way of knowing* what you might be missing. Any half-decent CS education gives you a very broad grounding in the field so that you'll know where to look and what you need to read up on when you find yourself stuck trying to tackle some problem. Without the grounding there's a real risk that you might end up fighting windmills or reinventing solutions that were already known in the 1970s. Note: I am not saying that *formal* education is necessarily the only way to get such a grounding, but it *is* a very reliable one assuming that, a) you find a half-decent university, and b) it suits your temprament, and c) you put in the requisite effort to learn about things that may not be of immediate interest. Regards, ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
