Re: [Haskell-cafe] Question about rpc design
snip Is this way of sending messages already known? Does it have a name? And if not, how hard do you think it would be to hack some rpc library to implement this? I think you are describing telescopic routing. Of sorts. The easiest way to achieve your goal is by making the communications asynchronous and the party which has an answer to send it directly to the originator. It won't necessarily reduce the latency though, and you would probably get multiple answers, unless you have no redundant data in the network. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Hemkay, the 100% Haskell MOD player
However, there seems to be a conflict between the nature of mixing and stream processing when it comes to efficiency. As it turns out, it's more efficient to process channels one by one within a chunk instead of producing samples one by one. It takes a lot less context switching to first generate the output of channel 1, then generate channel 2 (and simultaneously add it to the mix) and so on, than to mix sample 1 of all channels, then sample 2 etc., since we can write much tighter loops when we only deal with one channel at a time. On the other hand, stream fusion is naturally fit to generate samples one by one. It looks like the general solution requires a fusable transpose operation, otherwise we're back to hand-coding the mixer. Have you found a satisfying solution to this problem? I wonder if data-parallel haskell won't be able to help here, mod rendering is a scatter-gather style of processing, the problem is that the different channels trigger different processing. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Hemkay, the 100% Haskell MOD player
I would do resampling (with some of the Interpolation routines) and mixing in two steps, that is I would prepare (lazy) storable vectors with the resampled sounds and mix them. Since Haskell is lazy, this is still somehow on the fly, although one could still wish to eliminate the interim storable vectors. You could use stream fusion, although you will need to adapt that for the interpolation, but it should work. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Nano-Languages
An important question will be, Will syntax macros work out better than an existing tool such as Happy? They work in scheme, and typed scheme http://www.ccs.neu.edu/scheme/pubs/popl08-thf.pdf and a different hygienic mscheme is used in dylan http://people.csail.mit.edu/jrb/Projects/dexprs.pdf Both are based on pattern matching rewrite rules. Integrating a similar macro system in haskell should be possible, but definitely not trivial - how will it interact with the type system? Haskell is already halfway there, Template Haskell provides a platform to base them on http://www.haskell.org/ghc/docs/6.10-latest/html/users_guide/template-haskell.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Nano-Languages
If one were to think of this as a project, the initial project goal might be a proof of concept, that such an undertaking though non-trivial may be worth while. for me it is currently quite tough, since I don't know the internals at all It would be desirable to act on the abstract syntax trees that result from the compiler parsing the source code and not the source code itself. Template Haskell does that - it provides quotations, quasi-quotations and splicing, along with other utilities. I would guess that a simple design would be to add an import_syntax clause, similar to import, but importing only declarations with type ...- Q ... and splicing automatically their appearances. This is a back of the envelope design, and I haven't considered any potential side-effects, but sounds like a reasonable approach ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Nano-Languages
I'll try to paraphrase you, to see if I understand you correctly. The composition splice . quote can have one 'hard' error source. Grammatically incorrect quote. I think that will be caught by the type checker. Of a bigger concern are logical errors, introduced by buggy macros. But it is template haskell, so the same rules and tools apply. What I suggest is replacing the $x of template haskell, with S.x, where S is a module imported for syntax. What I'm not sure is how to deal with matching$(...). I'm not sure that the parenthesis can be avoided in all cases. On Thu, Dec 10, 2009 at 4:59 PM, John D. Earle johndea...@cox.net wrote: Vladimir, I do not mind becoming more familiar with the internals, but as you pointed out that Template Haskell may provided much of the needed functionality. I tend to doubt that it will provide all the needed functionality, however. The new syntax created by the syntax macros will either reinterpret a preexisting production in the language or will create a new one which may be based on a preexisting production, a variant. In the latter case, the compiler will have a knee jerk reaction. It will feel that the structure is grammatically illegal! This knee jerk would need to be intercepted and assigned an interpretation. We would then need to calm the compiler down and say its ok. -- From: Vladimir Zlatanov vl...@dikini.net Sent: 10 Thursday December 2009 0854 To: Haskell Cafe haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Re: Nano-Languages If one were to think of this as a project, the initial project goal might be a proof of concept, that such an undertaking though non-trivial may be worth while. for me it is currently quite tough, since I don't know the internals at all It would be desirable to act on the abstract syntax trees that result from the compiler parsing the source code and not the source code itself. Template Haskell does that - it provides quotations, quasi-quotations and splicing, along with other utilities. I would guess that a simple design would be to add an import_syntax clause, similar to import, but importing only declarations with type ...- Q ... and splicing automatically their appearances. This is a back of the envelope design, and I haven't considered any potential side-effects, but sounds like a reasonable approach ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lisp like symbols in haskell
I think stable names can be used where symbols are used in scheme. I think there are better alternatives for different use cases in haskell. For example, symbols are often used to tag values - haskell has pattern matching on constructors. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lisp like symbols in haskell
jeanchristophe.min...@gmail.com wrote: I think lisp like symbols could be quite useful in the context of embedded DSL to create ... well... symbols that can be interpreted as variables in that DSL. Well for such use-case you could use either stable names, or recode them into a state monad- you will get either a global i.e. lisp like unique symbols, or their equivalent within a state context. Or some variation of the code posted previously in this thread. http://www.haskell.org/ghc/docs/6.10.4/html/libraries/base/System-Mem-StableName.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. In my opinion it is the better than yielding True. 0/0 doesn't make sense. So it can't be compared to anything else which doesn't make sense. Whether == should yield False at all is another matter. It may be better to yield some kind of bottom (undefined?), but then compatibility with IEEE 754 might be an issue, hence using external libraries like BLAS, gmp, ... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] expanded standard lib
snip Many other programming languages have packaging strategies that sound very similar. Several of them have managed to have a negative impact on platforms that already have good packaging technologies (i.e. almost every platform apart from Windows ;-). I'd hate to see Haskell go in a direction where packaging for e.g. Debian is made more difficult than it is at the moment. :) That would be very bad indeed. With careful implementation that shouldn't be a problem. Му reference to planet was regarding the ease of use and download of packages not installed in the system. That is integrated into the compiler via scheme macros or their equivalent in non-scheme languages: - just consider the following: (require (planet eval.ss (dherman javascript.plt 5 4))) if a package javascript verssion 5 4 by dherman is not present in your system or your user planet cache - download, and compile it, then proceed doing your normal compiler duties With distribution provided packages they will be present if installed by root. With user downloaded they go somewhere in home or whatever else sensible place is pointed in the environment. I simply don't see a conflict. It is the normal unix way. Being lazy is good after all. Having the tools infer all dependencies and provide them to you when you need them is a good thing as well. Just compare it with the: sudo apt-get xyz; echo I don't have root, I'll call dad, 'cause I want to compile I'm not sure if it is currently possible to implement that via template haskell. From the snippets I've glimpsed it implements a simple defmacro like mechanism. But does it allow executing actions at compile time? If yes, it can be done in a library and then tested for usability, packaging and destruction. I do think it is wrong to have it in the prelude, at least for quite a while, but having the option to do it is a plus. I think I went oveboard with this. Sorry for the longish post. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] expanded standard lib
Yes, those are good points. Maybe adding functionality similar to plt's planet http://planet.plt-scheme.org and http://download.plt-scheme.org/doc/371/html/mzscheme/mzscheme-Z-H-5.html#node_sec_5.4 In plt scheme including a module, not present in the local repository , but included via planet, resolves the module, including version, etc..., downloads it from planet, and uses it appropriately. It makes following various dependencies extremely easy. Updating with a new version is updating the appropriate local module definitions. I have no clue how it would be best to implement this for haskell, but it is a very user friendly no hassle way to work, so I reckon worth investigating. Cheers, Vlado ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
