Re: The importance and relevance of FP
Richard <[EMAIL PROTECTED]> writes: > They still live in Emacs. (Emacs Lisp's variables are dynamically scoped.) OK. I tend to forget about this one, since I'm using it every day (and use the macro "lexical-let" unless I am sure that no evil things will happen). Ralf
Re: The importance and relevance of FP
Doug Ransom wrote: > I think you are mistakening ignorance for stupidity. It > is true that C/C++ programmers like to write OO and few > have any idea about functional programming, but very few > will miss the ability to constantly shoot themselves in > the foot with uninitalized random pointers, weird memory > access errors, and none will miss spending a couple of > weeks at the end of the development cycle trying to find > a memory leak. With such optimism about programmers, I'm astounded that you're writing from a .com rather than a .edu address. :-) My experience in industry has led me to quite different conclusions. Many C/C++ programmers seem not to recognize pointer issues as a problem, or at least, one with a viable solution; when offered languages with built-in GC, they say things like, "I like doing my own memory management; it gives me more control and makes it clearer what's really going on in the program." As I pointed out in a previous message, most of these people can't really handle the power that this "more control" gives them, but they have a blind spot that prevents them from recognizing that this is a problem. Craig
RE: The importance and relevance of FP
> > If C# again makes it easy to write unsafe code, then in order > to avoid the learning curve, many current C/C++ programmers > are likely to continue programming in The Old Way. The trick > lies in the learning curve. > I think you are mistakening ignorance for stupidity. It is true that C/C++ programmers like to write OO and few have any idea about functional programming, but very few will miss the ability to constantly shoot themselves in the foot with uninitalized random pointers, weird memory access errors, and none will miss spending a couple of weeks at the end of the development cycle trying to find a memory leak. Doug Ransom > --Ben > -- > Benjamin L. Russell > [EMAIL PROTECTED] > [EMAIL PROTECTED] > "Furuike ya! Kawazu tobikomu mizu no oto." --Matsuo Basho >
Re: Haskell for DSPs ?
Hi, For DSP with Haskell, I remember having seen 2 years ago a presentation by James Hook (Oregon Graduate Institute of Science and Technology, Pacific Software Research) on Hawk, which should be a Haskell derivative. http://www.cse.ogi.edu/PacSoft/ should be a starting point Hope it is relevant and helps, BR -Sylvan On Thu, 17 Aug 2000, Kwanghoon Choi wrote: > > Hello, > > I knew one relevant link for functional DSP: > > http://users.snip.net/~donadio/mpd-hs-dsp.html > > Kwanghoon > > On Thu, 17 Aug 2000, Axel Jantsch wrote: > > > > > Hi, > > > > I wonder if anybody has ever tried to develop a good compiler for Haskell > > or any other functional language for a DSP processor? > > > > There are no good C compilers for DSPs and much of DSP programming is still > > done in assembler, due to the irregularity of DSP instruction sets and the > > peculiarity of architectural features. > > > > I wonder if it wouldn't be an advantage to start from a functional language > > and derive compact and efficient DSP code by a possible very exttensive > > analysis? I guess the compilation of even small programs could take hours > > if only the results in terms of speed and code size is really good. > > > > Any language for which this is possible would be adopted immediatly without > > hesitation because the current practive of manual coding is really tedious > > and inefficient as you can imagine. > > > > Any pointers to work done in this direction would be greatly appreciated. > > > > --Axel Jantsch > > > > > > --- > > Axel Jantsch, Email: [EMAIL PROTECTED],http://www.ele.kth.se/ESD > > Phone: +46 8 752 1221, http://www.ele.kth.se/INTELECT > > GSM: +46 70 713 7428,Fax: +46 8 752 1270 > > Electronic System Design Lab, Department of Electronics, > > Royal Institute of Technology, Electrum 229,S-16440 Kista, Sweden > > > > > -- Do, or do not. There's no try. -Yoda Sylvan Ravinet: http://www.ravinet.com/sylvan/contact
Re: Haskell for DSPs ?
Hello, I knew one relevant link for functional DSP: http://users.snip.net/~donadio/mpd-hs-dsp.html Kwanghoon On Thu, 17 Aug 2000, Axel Jantsch wrote: > > Hi, > > I wonder if anybody has ever tried to develop a good compiler for Haskell > or any other functional language for a DSP processor? > > There are no good C compilers for DSPs and much of DSP programming is still > done in assembler, due to the irregularity of DSP instruction sets and the > peculiarity of architectural features. > > I wonder if it wouldn't be an advantage to start from a functional language > and derive compact and efficient DSP code by a possible very exttensive > analysis? I guess the compilation of even small programs could take hours > if only the results in terms of speed and code size is really good. > > Any language for which this is possible would be adopted immediatly without > hesitation because the current practive of manual coding is really tedious > and inefficient as you can imagine. > > Any pointers to work done in this direction would be greatly appreciated. > > --Axel Jantsch > > > --- > Axel Jantsch, Email: [EMAIL PROTECTED],http://www.ele.kth.se/ESD > Phone: +46 8 752 1221, http://www.ele.kth.se/INTELECT > GSM: +46 70 713 7428,Fax: +46 8 752 1270 > Electronic System Design Lab, Department of Electronics, > Royal Institute of Technology, Electrum 229,S-16440 Kista, Sweden >
Haskell for DSPs ?
Hi, I wonder if anybody has ever tried to develop a good compiler for Haskell or any other functional language for a DSP processor? There are no good C compilers for DSPs and much of DSP programming is still done in assembler, due to the irregularity of DSP instruction sets and the peculiarity of architectural features. I wonder if it wouldn't be an advantage to start from a functional language and derive compact and efficient DSP code by a possible very exttensive analysis? I guess the compilation of even small programs could take hours if only the results in terms of speed and code size is really good. Any language for which this is possible would be adopted immediatly without hesitation because the current practive of manual coding is really tedious and inefficient as you can imagine. Any pointers to work done in this direction would be greatly appreciated. --Axel Jantsch --- Axel Jantsch, Email: [EMAIL PROTECTED],http://www.ele.kth.se/ESD Phone: +46 8 752 1221, http://www.ele.kth.se/INTELECT GSM: +46 70 713 7428,Fax: +46 8 752 1270 Electronic System Design Lab, Department of Electronics, Royal Institute of Technology, Electrum 229,S-16440 Kista, Sweden
Re: The importance and relevance of FP
Ralf Muschall writes: > > simplistic, binary distinction), then you have to decide where to draw the > > line between "functional languages" and other languages that may, to some > > I think it became impossible to draw that line since the inventors > and maintainers of dysfunctional langauges learned that FP is cool > and added closures etc. (Perl has them since 5.001m, Javascript > since 1.2, just to mention a few). First, you might well include first-order (algebraic) languages in your definition of "functional". Second, if your language has a semantics, it is not very hard to draw a distinction: you just have to show an appropriate embedding of lambda-calculus. If your language has no semantics, then you are in for a world of trouble anyway, and the question of whether your language is (higher-order) functional will be the least of your worries. -- Frank Atanassow, Dept. of Computer Science, Utrecht University Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands Tel +31 (030) 253-1012, Fax +31 (030) 251-3791
Re: The importance and relevance of FP
> From: Ralf Muschall <[EMAIL PROTECTED]> > Date: 16 Aug 2000 21:46:44 +0200 > "Craig Dickson" <[EMAIL PROTECTED]> writes: > > simplistic, binary distinction), then you have to decide where to > > draw the line between "functional languages" and other languages > > that may, to some > > I think it became impossible to draw that line since the inventors > and maintainers of dysfunctional langauges learned that FP is cool > and added closures etc. (Perl has them since 5.001m, Javascript > since 1.2, just to mention a few). Yes, but in Perl at least you have to call a closure, or any function passed as a parameter, with a different syntax than a function defined at top level. To my taste, that's an important difference from 'real' functional languages. (Emacs Lisp wouldn't be a functional language either by this criterion). Lars Mathiesen (U of Copenhagen CS Dep) <[EMAIL PROTECTED]> (Humour NOT marked)
