This is something that comes up over and over on the list. I believe that there are others at U(U) that are working on this problem presently as a way to help port the runtime system from C. Perhaps it would be good to connect everyone up more efficiently.
On the more boring end, I'm working right now on a language with very overtly C-semantics for getting some of the benefits of pretty macros in C. I suspect that there is a connection between what I'm doing and Fulmar. But I can't seem to understand Fulmar from the docs and I have nothing doc-like to speak of us. Another thing in this realm is the Terra language --- http://terralang.org --- and its associated projects, which are all quite beautiful. Jay On Tue, Apr 19, 2016 at 3:18 AM, Konrad Hinsen <konrad.hin...@fastmail.net> wrote: > On 18/04/2016 19:20, Dmitry Pavlov wrote: > >> I, as a programmer in the area of numerics, just evolved to the state >> where the following task seem reasonable to work on: > > ... > >> I suspect I am not the only one who wants that. > > > Me too! > >> There must be some work already done. >> What would you advise to start with? > > > I am not aware of anything very close to your goals in Racketland, but there > are people much more knowledgeable than me on this list. > > I have played with similar ideas as well, but never found the means to work > on this seriously. But I'd participate in a collaborative project. > > My idea for this is: > > 1) Define a language with C-level semantics but S-expression syntax. A > language that can be easily compiled to C, Fortran, LLVM byte code, and > perhaps even JVM bytecode, in a way that the performance implications of > each statement are understandable to a software developer. > > 2) Develop whatever backends (C, Fortran, LLVM, ...) people find most > useful. But make sure that at least one backend integrates transparently > with Racket's FFI, so that one can "just run" such code from Racket. > > 3) Develop DSLs that compile to this language. > > In the long run, the low-level language could be extended by optimization > hints, similar to #pragmas as used in OpenMP. > > Symbolic derivatives and similar transformations would be part of the DSL > implementations. For the specific case of derivates, Jerzy's remark is > important: automatic derivatives are often the better choice. But for the > big picture, that's a secondary question; a numeric DSL framework should > support both approaches. > > Konrad. > > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Jay McCarthy Associate Professor PLT @ CS @ UMass Lowell http://jeapostrophe.github.io "Wherefore, be not weary in well-doing, for ye are laying the foundation of a great work. And out of small things proceedeth that which is great." - D&C 64:33 -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
