***catonano_ is now known as catonano
<marusich>What module provides the "rename" procedure? I'm looking at the manual and cannot see it. <sneek>Welcome back marusich, you have 2 messages! <marusich>Never mind, I was looking for rename-file. <marusich>To answer myself, it is built in - importable without using any modules explicitly - which is why no module was mentioned in the manual. Sorry for the noise! <lle-bout>I was wondering; could GNU Guile benefit from a noticeable speed bump aided by an hardware accelerator like an FPGA over PCI-e or OpenCAPI, or even standard USB? I'm thinking FPGAs come to give great opportunity to all interpreted languages to get up to speed with compiled ones, while still remaining modular. GNU Guile could dynamically reprogram an FPGA to aid itself at ever evolving tasks. <ArneBab>lle-bout: do you mean like a support-processor used by the JIT-compiler? <lle-bout>But it doesnt need to be about JIT-ing - it can be executing Scheme directly on the FPGA by programming an optimized interpreter to that FPGA, or compile Scheme directly to an FPGA circuit <lle-bout>ArneBab, there exist small FPGA that fit into a small USB stick, I'm wondering if these would be powerful enough to give GNU Guile any advantage, it'd be an interesting research area because I think it can bring us closer to an optimized "Lisp Machine" in the general sense, other interpreted or JIT-ed languages could also benefit from such a CPU+programmable accelerator combination <lle-bout>Ideally, consummer would start shipping with on board small FPGA for such purposes :P <ArneBab>lle-bout: so you mean something like compiling hot functions down to FPGA instructions? <lle-bout>ArneBab, that is a possibility but I'm thinking it's not quite as practical as having a specialized Scheme FPGA interpreter because reprogramming an FPGA dynamically isnt a fast process ***apteryx is now known as Guest61121
***apteryx_ is now known as apteryx
<ArneBab>lle-bout: ah, so you rather mean something like programming the FPGA for common functions in Guile? <lle-bout>ArneBab, writing a Guile Object interpreter in FPGA with DMA access from the FPGA, to interpret any code necessary hopefully faster <ArneBab>did you measure where Guile spends most of its time in processing? <ArneBab>(that could be a good starting point) <lle-bout>ArneBab, yes :-) - it certainly is, but I'm looking forward to such research topics, I have a POWER9 machine with PCI Gen4 on which I can plug an FPGA with very high speed I/O - I havent ran any measurements yet, just dreaming about a Lisp Machine revamp in present time :P <lle-bout>ArneBab, I have come to the realization that only dynamic languages such as Python, Lisp or Javascript, can allow for practical software freedom. The others just cultivate walls of their own that later can't be changed freely ever by users. <lle-bout>A complex language made for experts or structurally makes downstream patching difficult can't allow for software freedom. There needs to be a platform where everyone's happy in terms of performance and where there's no compromise to make on choosing other languages that provide worse practical software freedom due to difficulty of modification of the code base architecturally. <lle-bout>Lisp allows downstream patching straight into the language itself, without any external programs, and I think it's really valuable. In other languages you might obtain it with diffutils but it's not as easy. JavaScript, I think, is a great example of practical software freedom, and that's also why it really took off, but it's unfortunate that most developments are jailed in the Web APIs and that existing JIT compilers are so <lle-bout>memory intensive that they arent suitable for many applications. <ArneBab>lle-bout: Javascript is heavy in memory, because it is really hard to optimize for speed. That browser developers actually managed to make Javascript fast is sufficient proof for me that you can make almost every language fast by just throwing enough money and skilled people on it. <ArneBab>Scheme is special to me, because it frees the application developers from many of the limits traditionally imposed by having to use what the language designers expected. <lle-bout> https://bellard.org/quickjs/ - is a promising new JavaScript engine but I would've hoped that GNU Guile could become a standard for writing optimized language interpreters considering it has an intermediate representation, acting in some ways as the LLVM's specialized for JIT'ing <lle-bout>GNU Guile helping carry the software freedom ideals, ensuring they do not get lost in the process <lle-bout>ArneBab, well, as much as I'd like to agree with that, I also think Scheme itself imposes some design limits, e.g. recursivity <lle-bout>Rust procedural macros are also interesting, giving full access to internal compiler AST to parse and produce arbitrary AST from arbitrary text inside the macro call <lle-bout>I'm not very experienced in Scheme, but I don't think you could do such a thing <lle-bout>That is, without taking yet another huge performance hit which would encourage you not to do it in the first place <ArneBab>In Scheme you can do whatever you want in a reader extension. That’s how SRFI-105 and wisps dimension-guessing arrays are implemented. <ArneBab>you avoid that if syntax-case suffices (to reduce complexity) <ArneBab>you avoid syntax-case if syntax-rules suffices <ArneBab>you avoid syntax-rules if a procedure suffices <ArneBab>and you can always scale up to the more complex level, because they mostly act the same in code <ArneBab>And if all that isn’t enough, you can go for Guile mechanisms and write your own language. <ArneBab>lle-bout: my wisp work is implemented as language which does the smallest possible amount of work to get to arbitrary scheme to defer to regular Scheme. That way it gets almost all of the Scheme operations for free. → https://www.draketo.de/english/wisp <ArneBab>that’s roughly what I expected: making javascript fast is hard. <ArneBab>It would be interesting to run the bellard benchmark with Guiles ecmascript implementation in Guile 3.0 <manumanumanu>lle-bout: what? If anything, rust's procedural macros are inspired by scheme's. <manumanumanu>You can do arbitrary transformations on text. I could theorecitally implement a (rust ...) macro for compiling rust (i think, at least. There would be all kinds of ugliness to coerce runt into scheme i believe) <manumanumanu>Only a lot easier. Rusts procedural macros are complicated. <manumanumanu>lle-bout: and regarding recursion: I would say compiling things to scheme is simpler because of recursion: Having done a little bit of "transpilation" I would say that best case is where the target language supports Tail call optimization. Trying to force one kind of looping facility into another one is often awful. Rewriting any kind of iteration/looping system as tail recursive functions in generally a lot ***sputny1 is now known as sputny
***sneek_ is now known as sneek
<chrislck>just wondering: there's a 'sneaky' theme to most lisps: guile/racket/larceny/gambit <lloda>that isn't really lisp but specifically Scheme chrislck <lloda>Scheme was short from Schemer which came from Planner and similarly named expert systems of the time <lloda>most non-Scheme lisps are named like prefixlisp from what I can tell <butterypancake>is there a more concise way of doing the following? It just seems like a lot of guile to just replace periods with underscores <lloda>there is string-replace butterypancake <lloda>I have a string-replace-char somewhere which is a string-map one liner <lloda>(define (string-replace-char s a b) (string-map (lambda (c) (if (char=? c a) b c)) s)) <lloda>not more concise for a one off :-/ <catonano>rgherdt: anyway canonicalize-path is cool. I saw it in the past but misunderstood it ***amiloradovsky1 is now known as amiloradovsky