Johnny_Brahms

Transmission comes to mind. It as a gtk, osx and Qt GUI

I don't happen to agree with you on eliminating NIL. I don't understand what the royal pain is.

And dynamic-wind is the price you have to pay for call/cc. UNWIND-PROTECT is not the same thing. Multi-shot continuations is he reason. One way would be having explicit one-shot continuations and escape continuations. Those are faster and will make UNWIND-PROTECT work.

I am more in favour of delimited continuations though.

Delimited continuations makes that a bit simpler (since you can easily implement something like dynamic wind using them).

I am still waiting for all my favourite applications to be extendable in GNU Guile.

On a more general note, I am still waiting for the world to fall for lisp in general.

This was in a small valley near insbruck, Austria in the early nineties. It got some media attention due to some controversy regarding irresponsible tourists. I had however done my research and picked a slope that was regarded as low risk, which was unsurprisingly not reported b the local media :)

This depends on the type of avalanche. I know,because I was caught in one. The one I was in was relatively minor and made up of a large part newly fallen snow. I had stopped for a break and managed to get my skis back on, but the thing overtook me hundred meters later. I had managed to get to higher ground relative to the rest of the slope, which is probably what saved me. I broke one leg and both my arms and got a pretty bad concussion.

I managed to walk/ski (one ski was still on me, but badly broken ) to a nearby village and driven on a stretcher to the hospital.

I am lucky to be alive. It is amazing though how clear you can think in life threatening situations. the moment I noticed the avalanche I knew exactly what to do and where to go. When I was buried I remember rocking back and forth to get some wiggle/breathing room and when it stopped I waited until my mind cleared up, struggling hard to defeat the panic and pain, until assessing g the situation.

To anyone who was as confused as I, it is not the linked comment that is what OP is referencing, but a reply.

I think that the best way to go about it (at least if you want to be successful) would be to write a SRFI that could easily be impkemented using the FFIs that are already out there.

Managing that, but still being flexible enough to be useful, is a huge amount of work, at least if you want to do more than just "call this c function".

I have found that you fairly easily can write portable r6rs code, but whenever you step outside r6rs (for stuff that isn't standard, like networking) it becomes an exhibition of cond-expand abuse.

Because r7rs large is an effort that probably is bigger than common lisp. It is very much not a toy language.

I feel that not standardising a low level FFI for r7rs large is a mistake. They should at least recommend some reasonably low level stuff that can be used to build abstractions.

The simplest way would probably be to implement explicit and implicit renaming macro transformers. They are found in many schemes and are quite a bit simpler than the syntax case you linked to. Then you can just glue parts of ashinn's match.scm on top of it for the pattern matching.

There is also a srfi for an improved hygiene low level macro facility that is rather elegant. Can't remember the number though. 70-something.

I think immer is brilliant. I just saw that you have guile bindings, which makes it even more exciting!

I like that they are lgpl as well. I am a believer in that kind of freedom definition, and I hope you can dual-license it successfully.

    (define-syntax nest
      (syntax-rules ()
        ((nest x) x)
        ((nest x ... (y ...) z) (nest x ... (y ... z)))))

That one is quadratic according to the author, but for 1050 expands of a nest with 6 levels it is less than 10% slower. Whereas in chez scheme, the difference is even less (for more than 2000 expansions)

Edit: Decided to stress test the chez scheme macro expader. for 30000 expansions, it was under 1s using the syntax-case version. I'd say that is very much good enough.

Y'all should have a look at ewig which uses Immer - really fast persistent data structures for c++. Ewig is just a proof of concept, but the code is really nice. I have thought about taking that and building something bigger.

The upsides are the same as for a piece table (really simple undo/redo) but with the downside of not being able to just mmap a file. You also get basically zero memory usage when you do cut and paste (you can paste a file into itself until it is bigger than RAM without problems, since you are actually not copying the contents, just the pointer)

Look at the YouTube video as well. It is all very cool, at least if you are not already spoiled by using clojure :)

https://github.com/arximboldi/immer/blob/master/README.rst

Edit: Forgot to mention: Ewig can be found among Immer's author Arximboldi's repos. On my phone right now on GPRS connection, so maybe another friendly soul can provide the link.

It is already in use in a bunch of smaller editors like Vis (iirc)

Wow. I really thought there would be more energy in an earthquake. That's just like a smallish nuke.

It's not in r7rs small, but t will probably find it's way into r7rs large:

http://trac.sacrideo.us/wg/wiki/YellowDocket

R7rs small is a language in the spirit of r5rs. R5rs large will have a specified low level macro facility, probably syntax-case in one form or the other.

The smaller standard does not specify a low level macro facility. That doesn't mean that an implementation won't have one. No scheme has syntax-rules only.

I agree that the defmacro is simpler, but nobody said otherwise. The nest macro is more or less perfect for defmacro since it doesn't need hygiene.

If defmacro is so Important, there are several schemes with it out there, and if you really need it it is trivially implemented using low level hygienic macro facilities.

I don't get the obsession with defmacro vs syntax case. Defmacro can be implemented in syntax case in about 10 lines, whereas the power of syntax-case is very much non-trivial to implement in CL.

As an Emacs enthusiast I agree with that (GP's) statement. VScode is usable for everyone from the start yet is capable to grow just like vim and in most meaningful ways just like Emacs.

I have a feeling that this approachability is what will win in the end.

It won't win me over, but my investment in Emacs can be measured in over 50kb of elisp code :)

It surprises me to no end that programming languages that promote a functional style with higher order functions do not support partial application as a part of the standard library. It covers 95% of the uses of curried procedures and gives you compiler warnings if you pass too few or too many arguments.

In scheme we have the cut macro that all self-respecting implementations provide which guarantees you zero runtime overhead.

A question about urbit: whenever I read anything concerning it, all I see is a weird programming language and warning signs of esoteric technocratic fascism.

What is it that people find fascinating?

Some People use evil, which is hands down the best vim emulation out there.

I myself started with evil after a long time with vi(m) and then made the switch to a more "pure" (for the lack of a better word) Emacs experience.

I am still very proficient with vim, even though Emacs has been my daily driver for 4 years.

Wiuldnt implementing those be trivial? They are hardly going to be "too slow" like file copy might be, and with the JS love of small packages this should already be a solved problem.

I wouldn't compare them. I would say most people know about what the US did in Chile (and over most of south america), whereas the russian involvement in US domestic politics is still rather opaque.

And even if they were comparable, one can still find both despicable.

Maybe not hero, but I thoroughly enjoy Andy Wingo's writings and talks. Every time I forget that programming is fun, I go to his blog.

He really likes what he does and is a very inspiring individual, and does a lot to bridge the gap between academia and us regular folks.

> A different programming paradigm, for instance, would be the use of delimited continuations such that the API you invoke suspends the current call stack, executes the I/O operation, then resume the call stack with the result of the I/O operation.

guile has recently gotten guile-fibers which works like this. It is really an amazing way to do concurrency.

wingolog.org

Andy Wingo's texts about compilers and optimisation. Very nice, especially if you like scheme.

Whatever implementation you have access to that is considered safe. That probably means AES-GCM or chacha20+poly1305.

Use whatever vetted AEAD mode that is available to you. That probably means AES-GCM or Chacha20 + Poly1305).

If you don't have any very good reasons to use CTR (encrypting lots of data with the same key) you.probably shouldn't.