#+TITLE: 028/ 100daystooffload Once More With Swanky Feeling
#+author: screwtape
#+PROPERTY: header-args:lisp :session *lisp*
#+PROPERTY: header-args:lisp :cache yes
For fear of duping myself a fifth time, and remembering our once-only
pledge, let's start a swank session using elisp in emacs, and connect
to it, having a named session.

I assume you have slime for lisp in your emacs already. The
dependencies are obvious (or ask me).
* Just 
** Register lisp in orgmode
#+name: register-lisp
#+begin_src elisp :results none
  (org-babel-do-load-languages
   'org-babel-load-languages
   '((lisp . t)))
#+end_src

** Starting swank in an eshell
Actually, org-babel is aware of eshell itself (!)
#+name: start-eshell-swank
#+begin_src elisp :var my-lisp="sbcl" my-slime-path="~/common-lisp/slime-v2.27/"
  (eshell)
  (dolist (cmd `("cd"
		 ,(format "cd %s" my-slime-path)
		 ,(format "%s --load start-swank.lisp" my-lisp)))
    (insert cmd)
    (eshell-send-input))
  (previous-buffer)
#+end_src

#+RESULTS: start-eshell-swank

** Connecting to the running swank

#+name: connect-slime-to-swank
#+begin_src elisp :var my-swank="localhost" swank-port="4005"
(slime-connect my-swank swank-port)
#+end_src

#+RESULTS: connect-slime-to-swank
: #<process SLIME Lisp>

** Requiring mcclim
#+name: require-clim
#+begin_src lisp
  (progn
    (require :mcclim))
#+end_src

#+RESULTS[29e19ba0d4582dc23040e41c83eb1f9078457c57]: require-clim
: #<PACKAGE "CLIM-USER">

** Are we still in clim-user, slime confuses me
Alright, annoyingly here I had to go change the package in my *slime-repl*
to :clim-user manually ==(in-package :clim-user)==
#+name: lisp-session-package
#+begin_src lisp :results output
(present '1)
#+end_src

#+RESULTS[2144da066c3df4a64a263097b90eaad98cb0597f]: lisp-session-package
: 1

** It's under foot. ACTUALLY NEW CONTENT
I figure the crux of lots of things benefit from the implied
constraints (great, great exploration) of using ANSI CLIM2's PRESENT
and ACCEPT. Hence let's make a class that #'PRESENTs a slot.

This is my hello, world. A line that's kind of useful and also a
nearly microscopic granularity, to be performed once and built upon in
the future.
#+name: certain-present
#+begin_src lisp :results output
  (defclass certain-present ()
    ((presenting-slot :initarg :presenting-slot :accessor presenting-slot)
     (foo :initform '1 :accessor foo)))

  (define-presentation-type certain-present ())
  (define-presentation-method present
      (obj (type certain-present) stream (view clim:textual-view) &key)
    (let* ((slot (funcall (presenting-slot obj) obj)))
      (present slot)))
  (setq *eg* (make-instance 'certain-present :presenting-slot 'foo))
  (print (funcall (presenting-slot *eg*) *eg*)) (terpri)
  (present *eg*) (terpri)
  (present *eg* t :stream t) (terpri)
  (present *eg* 'certain-present :stream *standard-output*)
#+end_src

#+RESULTS[0e4b85b6cdf162109b9932f43147879706296307]: certain-present
: 
: 1 
: 1
: #<CERTAIN-PRESENT {1008CEF563}>
: 1

that should really #'APPLY and pass through arguments. Future clobber!
** Alright that seems of limited utility
But the gist is a class that knows when it is presented, I mean
present a particular slot of it. I guess it might be more idiomatic to
use #'WITH-SLOTS to pull a slot (with an interesting type, like
integer or list) out of the class instance, and then explicitly
present that slot. I guess the point of this class was to not know the
presentation type of the slot being presented (???).

Note that if I use another presentation type, like t toplevel I get
toplevel's #'PRESENT (write the unREADable class instance).

** But the gist was
that in implementing all of
| veilid | gopher | gopherMOO <as such> | gopherMOO <slates> |
each of these I can circumscribe communication interfaces by farming
them all out to CLIM2 'PRESENTATION-TYPEs, whether node-to-node onion
layers in veilid, or rfc1436 request/response, or the client
PRESENTing its rich media interface via colored lights and sound.

Arriving here, I also start by having a rich graphical interface for
myself and realise onionish routing unostentatiously as class
instances sitting in one lisp image- which, eventually, PRESENT over
some internetworked communication protocol.

* Exploratory programming is the opposite of top-down design-design-design programming
The discovery of the seventies and early 80s was that Good Design, as
popularly exercised by Businesses (and Governments, though I repeat
myself) was actually the destruction of powerful ideas at the
hands of Good And Responsible Design And Planning.

In contrast, the exploratory programming grows new programs one to one
with the gestures of the programmer (here, I am starting with these
being append-only org-mode lisp session SRC blocks). What the final
system is like is too sophisticated to guess from a thousand-mile
Requirements Document And Checkpoints.

There are standards (the extremely knowledge-laden Common Lisp and
Common Lisp Interface Manager standards, the bite-sized frozen gopher
snack) and the quest of discovery records from gopherMOO. Creation of
an effective standard is possible, though somewhat frought exercise as
related by Kent Pitman:
[[nhplace.com/kent/Papers/cl-untold-story.html]]. For this reason I am
moving hazily towards the evolving (though released!) [[veilid.com]], and
sticking to clim2 [[codeberg.org/McCLIM/McCLIM]] (basically instead of
emacs as such). Gopher [[gopher://gopher.club]] being the sufficiently
sm0l and frozen internetworked target, and gopherMOO as an exploration
of virtual reality through physically entering the gopher together.