On Lisp Puns

As the title says, I'm in a bit of dilemma on how to approach the dialogue for a character who gets seriously beaten up and loses his teeth. For the record, said character is only seen in that scene relatively briefly during a heated argument.

So far, I've mostly replaced the S's with TH's like this:

*“What ruleth man?” One of his eyes started rolling back involuntarily in its socket. “It’th kill or get killed. I’m dthust trying to thurvive too. *

The thing is he has a few more lines and I'm worried if my readers will be able to read them easily or not.

What do you think? How would you approach something like this?

Thanks!

Okay what exactly is he implying when he says that? I'm racking my brain to find the double entendre or what the joke is. Unless it's just a non-sequiter.

I'm curious to hear everyone's thoughts on this.

What if a project was written ENTIRELY in Common Lisp.

Where the shell commands for building the program are wrapped in Common Lisp, the documentation, and everything in between.

Would this even be feasible?

My thoughts are that this would be kind of neat.

What is going on? Did Dan just come from Palace?

I don't know if it's the Canadian accent or what. I feel like Caitlin did as well as Craig. Even Ellie kind of did in season two.

Thanks

Hey Lispers,

This one was a quick holiday project of mine, which I'm sharing with you -- cl-wol: Wake on LAN (WoL) system for Common Lisp.

Happy holidays!

https://github.com/inconvergent/weird

https://preview.redd.it/w6mfpnvn55581.jpg?width=1200&format=pjpg&auto=webp&s=eca10203d02106d1a6fe3890a9043d62bca0f4a7

Syntax is ever a contentious subject. Nominally it doesn't matter, and for the most part our IDEs pick up the slack.

LISPs and FORTHs (i.e. concatenative languages) tout the property of homoiconicity. Like the 'everything is an object'-ness of big OO languages, except at a syntactical level.

Homoiconicity is not about simplicity of metaprogramming, but the simplicity of the parser. In FORTH in particular, the parser can be written in a few hundred assembly instructions, and can be re-bound at runtime, allowing the language to bootstrap itself to more complex syntax. Meanwhile, parsing S-expressions is little more than balancing parentheses and CommonLisp allows hooking macros up inside the parser to change the syntax directly.

While homoiconicity does have this desirable property, and meta-programming to boot, the tradeoff is that code is distinctly harder to read.

Most concatenative programming languages in the FORTH family, such as Factor, has extensive batteries-included meta-programming to allow e.g. the capture of local variables. The well known quadratic root formula is a nightmare to do purely stack-based.

CommonLisp similarly has a lot of heterogenous syntax for quotations, literals of both scalar and compound data structures, and loop constructs.

Which brings me to APLs. APLs are hard to read. APL itself, J, and even innovative newcomers like BQN (which does some great work, look into it if you are at all interested in array programming.)

The thing APLs bring to the table in exchange for this obscure syntax is extremely high code density. Very complex (not complicated) operations on data can be expressed simply as compositions more base operations. In terms of pure data-manipulation they are hard to beat.

However, the syntax is an expensive price to pay. Array programing can these days be done in easier-to-read languages with mere libraries (Numpy comes to mind in particular) to virtually identical effect.

At the same time the compositional nature of the array syntax is, at a most basic level, a fairly restricted form of higher-order functional programming.

Which brings me to the conclusion:

Is weird syntax bad? No! By all means, push the envelope. Learn these languages, design even weirder ones. This is how language innovation is made.

But in doing so, be aware — not wary, just aware: most people have encountered infix notation is elementary school. Most people are accustomed to words forming sentences. The more you deviate from the

Day 1:

Braces installed with bite pillows as well to help correct overbite (like bite blocks but instead two lumps of hardened gel on my left and right upper molars)

Realize when talking to someone an hour later I now have a lisp while never having any speech issues prior

Day 2:

Googling everything in-site to gauge when it goes away, mixed feelings

Fast forward 6 weeks:

I am at the ortho yesterday and this lisp is still here. They are correcting the overbite but I am trying to ask them if they think the lisp will go away and they basically tell me they think it’s because the bite pillows but can’t make any guarantees, I basically side with them but at the same time am super nervous.

On one hand it’s only been six weeks, and I am thinking of just calling it quits since it’s early on, and I keep reading things about how the lisp should go away after a few weeks...and here I am after six.

I am at the point where it’s 51/49% of keeping them versus just saying screw it and getting them off (farewell $6,000)

I don’t mind the pain or anything, it’s just that I am scared of the lisp being permanent. Any one else have the lisp for an extended period of time (how long) after having bite pillows, but then have it go away, or then having it go away as your overbite was corrected and the braces did their magic? This is my first ever post on Reddit so sorry about structure. I am going to call and ask another orthodontist at that office about the situation in more detail but appreciate any and all feedback

I think I built a working lisp shell reusing nixpkgs facilities for generating quiklisp package expressions. The code quality isn't really great but you can have a look at it here.

Hello,

I am always curious about differences in programming languages and when I found about about Prechelt's paper comparing Java, C++ and scripting languagse, as well as the folowup paper "Lisp as an alternative to Java" (all links in my article about it), I decided to look into it and see how the more modern languages today perform.

Common Lisp beat all other languaes in LOC, except Julia, was the fastest by a good margin (Java only beat it for the largest input files and when using a Trie algorithm that's much more efficient for the problem) compared with Rust, Java, Julia and Dart.

In memory consumption, it was only behind Rust, and even then by a small amount.

As someone who is not familiar with Lisp, that shocked me. I expected Java 16 and Rust to leave Lisp in the dust, to be really honest, but Common Lisp trashed my expectations.

I am now trying to learn Common Lisp, even if it seems to be going down in popularity and attention from the programmer's community (does anyone have hints for someone who is really comfortable using Jetbrains IDEs and finds emacs a bit too much of a barrier to overcome??)... I care about results like this a lot, not about hype!

Take Julia for example: it performed abysmally, much slower than any other language I tried... still , it's being hugely hyped as being the best language around (I got a few Julia experts to submit better implementations: they are all still on the same level as the one I wrote myself, just slightly faster).

Kudos to the Common Lisp people for sticking with what appears to be one of the best languages around even after all these years!

i meant to say to not do

Hi,

I just set up a new host with Xubuntu 20.04 LTS which comes with GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.14) of 2020-03-26, modified by Debian.

Of course, I'm reusing my config from here which worked on Emacs 28.0.50 (my previous host that died and had a snapshot release installed which I could not re-install) and which still works on Emacs 26.3 on another Xubuntu 20.04 LTS machine - the very same Emacs version.

Therefore, I'm puzzled of this error message on startup:

 Debugger entered--Lisp error: (void-function make-closure)
   make-closure(#f(compiled-function (url arg) #<bytecode 0x12db8d9>) "ftp")
   byte-code("\300\301\302\303#\210\304\211\203\035\0\211@\300\001\302\305\306\005\"#\210\001A\266\202\202\007\0\207" [org-link-set-parameters "help" :follow org-link--open-help ("ftp" "http" "https" "mailto" "news") make-closure #f(compiled-function (url arg) #<bytecode 0x12db8d9>)] 8)
   require(ol)
   byte-code("\302\303!\210\302\304!\210\302\305!\210\302\306!\210\010\307=\204;\0\3101*\0\311\312\011!\313P\314\315\211\211%0\210\202;\0\210\316\317!\210\320\321!\210\316\322!\210\320\321!\210\302\323!\210\302\324!\210\302\325!\210\302\326!\210\302\327!\210\302\330!\210\302\331!\207" [this-command load-file-name require cl-lib calendar find-func format-spec eval-buffer (error) load file-name-directory "org-loaddefs.el" nil t message "WARNING: No org-loaddefs.el file could be found from where org.el is loaded." sit-for 3 "You need to run \"make\" or \"make autoloads\" from Org lisp directory" org-macs org-compat org-keys ol org-table org-fold org-cycle] 6)
   require(org)
   eval-buffer(#<buffer  *load*> nil "/home/vk/.emacs.d/init.el" nil t)  ; Reading at buffer position 1590
   load-with-code-conversion("/home/vk/.emacs.d/init.el" "/home/vk/.emacs.d/init.el" t t)
   load("/home/vk/.emacs.d/init" t t)
   #f(compiled-function () #<bytecode 0x1e0f4d>)()
   command-line()
   normal-top-level()

This error message is invoked at the (require 'org) line right at the start of my init.el:

 (package-initialize)
 
 (defvar my-init-el-start-time (current-time) "Time when init.el was started")
 (setq my-user-emacs-directory "~/.emacs.d/")
 
 ;; set paths to manually installed Org-mode (from git; instead of built-in Org-mode)
 (add-to-list 'load-path (concat my-user-emacs-directory "contrib/org-mod

Karl Lehenbauer, CTO of FlightAware and longtime TCL contributor, will be presenting (virtually) next week on TCL at the Houston Functional Programming Users Group. Please join us! Complete details and connection info are on our website at https://hfpug.org

Hello. Does anyone know at what point the lisp disappears? I’m day 1 of tray 4 and it’s just not going away. The letters S, C and Z are just hard to pronounce. I have a small gap between my top and bottom teeth but when I put the trays on, the gap gets bigger thus the lisp. Is this something i should worry about? I’ve been reading and some people say that it might be because the trays don’t fit well.. idk if this applies to me.

Thanks!

I'm trying to write an emacs w3m filter for duckduckgo lite. I thought it would be cool to leverage magit-section, and have each result in its own section. So I have a function for inserting the sections from parsed 'result-groups' (a group is all the DOM material for one result):

(defun my/w3m-insert-duckduckgo-section (group)
  (let ((href (cdar (cdadar group)))
    (title (caddar group))
    (body (cddr (nth 1 group))))
    (magit-insert-section (result)
      (magit-insert-heading (insert (format "%s\n" title)))
      (insert (format "%s\n" "this-is-the-body")))))

I'm using the "this-is-the-body" string in place of an actual body at the moment, because I haven't got round to learning about parsing DOM text yet.

I run this in a loop over all the groups, inserting each one. This runs inside a root section I insert first.

This inserts the relevant text, but with no special properties (e.g. magit sections normally have certain faces) and no newlines. Everything is on one line, just running on to the next result.

If I run something like this in a scratch buffer, the result is correct:

(magit-insert-section (root)
  (magit-insert-section (result)
(magit-insert-heading (format "%s\n" "Header text 1"))
(insert (format "%s\n\n" "this-is-the-body")))
  (magit-insert-section (result)
(magit-insert-heading (format "%s\n" "Header text 2"))
(insert (format "%s\n" "this-is-the-body"))))

Running eval-last-sexp after this in the scratch buffer works exactly as expected (standard magit section text properties, newlines are printed correctly). What's most stange is that if I use eval-expression to run the above form in a w3m buffer, it works correctly! Correct faces and properties etc.

So, why do the newlines and properties not show up in the w3m buffer when I call the forms programatically vs interactively, and how can I fix this?

TIA!