Interview postponed / let's just talk about #types and #typing today's show on @dougmerritt and @vnikolov 's suggestion below.
(I'll speak a little bit to #Sandewall 's #SoftwareIndividuals #knowledgerepresentation
If anyone knows anything about #typetheory, that would be great.
anggtwu.net/math-b.html
hanselman.com/blog/stringly-ty…
blogs.perl.org/users/ovid/2010…
type links welcome
and #lisp
@shizamura possibly you can explain types of OWL to us instead of sleeping?
Stringly Typed vs Strongly Typed
I used to call this technique 'type tunnelling' and noted its use in XML in ...www.hanselman.com
This entry was edited (1 week ago)
reshared this
Vassil Nikolov
in reply to vintage screwlisp account • • •vintage screwlisp account reshared this.
Eduardo Ochs
in reply to vintage screwlisp account • • •Hey, I thought that today would be only a sound check, not the real interview... I am not prepared for the real interview! 😬😬😬
Can we postpone it? I will be super busy until may 20 - but I'll be have lots of time afterwards...
DougMerritt (log😅 = 💧log😄)
in reply to Eduardo Ochs • • •Since it's now getting to be last-minute, to save screwtape's theme for today, it could just be about different things people mean by "types", laying the groundwork for whatever you have in mind later.
For instance, we could all roundly criticize "stringly typed"[1] 😉
[1] one of a zillion search results: hanselman.com/blog/stringly-ty…
@vnikolov
Stringly Typed vs Strongly Typed
www.hanselman.comVassil Nikolov
in reply to DougMerritt (log😅 = 💧log😄) • • •@dougmerritt
dougmerritt> we could all roundly criticize "stringly typed"
Yes, the latter is a far, far cry from (say) typed lambda calculus (among others).
By the way, note that lisp's eval does not take a string as its argument (unlike some other languages).
#Lisp
#StringlyTyped
vintage screwlisp account
in reply to Vassil Nikolov • • •oh, sorry for the confusion! We can have a soundcheck before the show and /no/ interview.
@vnikolov @dougmerritt
types sound good. One thing I find confusing in Sandewall's work is that his typing was "you /must/ set an entity's type in its plist and are encouraged to use it []" (and 'new types' are entities of type thingtype)
vintage screwlisp account reshared this.
vintage screwlisp account
in reply to vintage screwlisp account • • •I guess you two remember I keep mentioning Goodwin 1981's Why Programming Environments Need Dynamic Types, in which Goodwin is basically suggesting lisp programmers to actively use DEFTYPE and TYPECASE (though at the time of writing, these were still congealing). Of course DEFCLASS and DEFSTRUCT implicitly DEFTYPE.
Goodwin, James W. "Why programming environments need dynamic data types." IEEE Transactions on Software Engineering 5 (1981): 451-457.
@eduardoochs
vintage screwlisp account reshared this.
vintage screwlisp account
in reply to vintage screwlisp account • • •in languages that handle PARSE-INTEGERable strings /such as #javascript (#Kitten)/ is the equivalence (sometimes) of "1" and 1 an example of defeasible inheritance?
In that
c = a - b
if c is 2 and a is 3, b might be a positive integer 1, or it might be a string "1" in js. #programming #types #defeasibleInheritance
@eduardoochs
vintage screwlisp account reshared this.
DougMerritt (log😅 = 💧log😄)
in reply to vintage screwlisp account • • •@eduardoochs
That's something to argue about.
Some people like that kind of thing for rapid development.
Some people like the strongest possible typing in order to catch human error.
vintage screwlisp account reshared this.
vintage screwlisp account
in reply to DougMerritt (log😅 = 💧log😄) • • •@vnikolov @eduardoochs
vintage screwlisp account reshared this.
DougMerritt (log😅 = 💧log😄)
in reply to vintage screwlisp account • • •Strong typing comes in both static and dynamic flavors, although some people use more ambiguous terminology.
vintage screwlisp account
in reply to DougMerritt (log😅 = 💧log😄) • • •@vnikolov @eduardoochs
Digital Mark λ ☕️ 🕹 🙄
in reply to vintage screwlisp account • • •@eduardoochs That's the response of strong-typing fans, whatever they mean by that. If you're more a hippie dynamic coder:
Strong Typing: Like a cop sitting on my desk.
Weak Typing: Loose, easy, and groovy, man.
vintage screwlisp account reshared this.
vintage screwlisp account
in reply to Digital Mark λ ☕️ 🕹 🙄 • • •Sensitive content
@dougmerritt @vnikolov @eduardoochs
Digital Mark λ ☕️ 🕹 🙄
in reply to vintage screwlisp account • • •Sensitive content
vintage screwlisp account
in reply to Digital Mark λ ☕️ 🕹 🙄 • • •Sensitive content
@dougmerritt @vnikolov @eduardoochs
Vassil Nikolov
in reply to vintage screwlisp account • • •@eduardoochs
What really matters is the amount of work to _fix_ or _change_ a program.
If you are so lucky to always write new programs that someone else fixes later and that never change, you can be comfortable with a lot of things...
vintage screwlisp account reshared this.
Kat
in reply to Vassil Nikolov • • •Leaping in after the fact from the wrong timezone, this is what swung me over to preferring stronger typechecking - "me sowing: What the fuck. This sucks."
And as I think this through, I've learned to prefer front-loading as much of the thinking as I can, in pretty much any context. I'm good at figuring out other people's thinking after the fact; I just resent having to waste my time doing it. Especially when the other person is my past self.
Maybe there's a "two types of people" thing here: those who prefer to minimise future issues for themselves, and those who prefer to smash it out and clean up afterwards, and some change over time from one to the other.
@screwtape @dougmerritt @eduardoochs
vintage screwlisp account
in reply to Kat • • •@KatS
I drew attention to Goodwin 1981 at the start because I like his framing of the problem of not having dynamic data types: That in a nontrivial (heh, trivial) environment, you simply don't know how much memory you're going to have to allocate (what type you're going to define) a day in the future.
This makes me suspicious of anyone claiming they've always figured every thing they're going to do, start to finish out (and documented it in confluence).
@vnikolov @dougmerritt @eduardoochs
Vassil Nikolov
in reply to vintage screwlisp account • • •@KatS @eduardoochs
screwtape wrote:
<">
This makes me suspicious of anyone claiming they've always figured every thing they're going to do, start to finish out (and documented it in confluence).
</">
Oh, I am quite willing to believe such a claim.
Whether they (or myself, to be honest) have figured it out _correctly_ is a different matter...
(Irony.)
Digital Mark λ ☕️ 🕹 🙄
in reply to vintage screwlisp account • • •@eduardoochs I'm the classic "strong typing is for weak minds" guy, having done too much web dev, BASIC, REXX, shell scripts, etc. These let you trivially use strings as numbers, because user input is more important than "correctness" whatever that is.
If your focus is all careful math with units, then you want typing of some kind, but most of us code junky dialogues with users or real-world text files, so loose string handling is good.
#types #programming
vintage screwlisp account reshared this.
vintage screwlisp account
in reply to Digital Mark λ ☕️ 🕹 🙄 • • •I have this fantasy scenario though where I write a strongly typed program in the ACL2 lisp automatic theorem prover, and it automatically proves a bunch of useful lemmas, and then through curry-howard correspondence I somehow get those lemmas as a lisp package for outside lisp.
okay, it has never happened yet, but like, it could, right?
@vnikolov @dougmerritt @eduardoochs
Digital Mark λ ☕️ 🕹 🙄
in reply to vintage screwlisp account • • •@eduardoochs Fantasy: Engine gives you awesome new information.
Reality: Fatal error: Type <T<Q:E>,D> unsatisfied at char 31,969.
#programming #types
vintage screwlisp account reshared this.
Vassil Nikolov
in reply to vintage screwlisp account • • •@mdhughes @eduardoochs
It could, but it is a lot of work to make it happen and there is too little demand to justify that work.
clew
in reply to Digital Mark λ ☕️ 🕹 🙄 • • •But then Little Bobby Tables comes along…
Who has implemented “janky” as a type?
@mdhughes @screwtape @vnikolov @dougmerritt @eduardoochs
Digital Mark λ ☕️ 🕹 🙄
in reply to clew • • •@clew @eduardoochs The REXX data type is anything: string, integer, floating point with potentially bignum precision, or stem (associative array, key/value can be anything, by convention(!) .0 is length of an indexed array).
It's incredibly liberating if you just want to solve problems. It's scary to type-safety people.
#programming #types
vintage screwlisp account
in reply to Digital Mark λ ☕️ 🕹 🙄 • • •Scary things:
cs-user> (typep (1+ most-positive-fixnum) 'integer)
t
cs-user> (typep (1+ most-positive-fixnum) 'fixnum)
nil
How often do numbers 281474976710656 or higher actually happen ;p
@clew @vnikolov @dougmerritt @eduardoochs
vintage screwlisp account reshared this.
Digital Mark λ ☕️ 🕹 🙄
in reply to vintage screwlisp account • • •@clew @eduardoochs
;; chez
;; dec is (fx- n 1)
> (dec (expt 2 59))
576460752303423487
> (dec (expt 2 60))
Exception in fx-: 1152921504606846976 is not a fixnum
Type (debug) to enter the debugger.
> (most-positive-fixnum)
1152921504606846975
Hrmn. If I avoid fixnum ops, I can let numeric tower pretend bignums are integers. I just need to make some ops that treat all strings as numbers, too.
vintage screwlisp account reshared this.
Vassil Nikolov
in reply to vintage screwlisp account • • •@mdhughes @clew @eduardoochs
screwtape> How often do numbers 281474976710656 or higher actually happen ;p
Depends on the domain.
The first example that comes to mind:
often enough if you calculate products of, say, 512-bit primes.
vintage screwlisp account reshared this.
Hunter Jozwiak
in reply to Vassil Nikolov • • •vintage screwlisp account
in reply to Hunter Jozwiak • • •was mainly that with the tiny changes of 1+ chaing the number's type as a side effect, the program's behaviour radically changes (bignum + not fixnum +).
@mdhughes @clew @eduardoochs @dougmerritt
Vassil Nikolov
in reply to vintage screwlisp account • • •@sektor @mdhughes @clew @eduardoochs
> there is a countable infinity of them
Pedantically, if you ignore that memory isn't unlimited.
> tiny changes of 1+ ... the program's behaviour radically changes (bignum + not fixnum +).
I see now.
That is a different point and yes, we ought to be aware of such things.
I can't improvise a proper discussion right now, but also compare to reading memory addresses past the end of a CPU cache line.
vintage screwlisp account
in reply to Vassil Nikolov • • •I finally got to the end of @smlckz ' article which I think captured some of our discussion here:
Static type checking shows that a program either is correct or else might be correct
and dynamic typing = testing shows that a bug either is present or else might be present.
@vnikolov @sektor @clew @eduardoochs @dougmerritt
vintage screwlisp account reshared this.
Digital Mark λ ☕️ 🕹 🙄
in reply to vintage screwlisp account • • •@smlckz @sektor @clew @eduardoochs
Static checking can only show that the program passes types down consistently, it says nothing about the logic or correctness of the program itself.
function addints(int x, int y) : int { return 3; }
is "consistent" and "type-safe", it returns an integer. But it's not "correct" for anything except addints(1,2).
Unit tests will quickly expose that addints is incorrect, even if you remove all the types.
#programming #types
vintage screwlisp account
in reply to Digital Mark λ ☕️ 🕹 🙄 • • •Unrelatedly and apropos nothing at all I mentioned satisfies before.
cs-user> (defun all-odd-p (sequence)
(notany 'evenp sequence))
all-odd-p
cs-user> (deftype very-odd-sequence () `(and sequence (satisfies all-odd-p)))
very-odd-sequence
cs-user> (typep #(1 3 5) 'very-odd-sequence)
t
cs-user> (typep #(1 3 5 2) 'very-odd-sequence)
nil
and I guess typecase - dynamic typing stuff. Idk (the very-odd-sequence foo)
@mdhughes @smlckz @vnikolov @sektor @clew @eduardoochs @dougmerritt
vintage screwlisp account
in reply to vintage screwlisp account • • •Sorry I had a misplaced reply. Another of the author's 8 points (surely you have to read the whole article to get the reward segment yourself, and not just skip directly to the bottom of the page) is
1. For what interesting properties of programs can we build static type systems?
So I guess the key thing about types is that they have to be syncronised to some kind of actual meaning.
@smlckz @vnikolov @sektor @clew @eduardoochs @dougmerritt
Vassil Nikolov
in reply to Digital Mark λ ☕️ 🕹 🙄 • • •@mdhughes @smlckz @sektor @clew @eduardoochs
The point is not that static type checking is omnipotent: it isn't, of course.
The point is that it catches _very many_ mistakes that programmers are _prone_ to make.
I say again: mistakes that are _often_ made, not all that can be made _in principle_.
> function addints(int x, int y) : int { return 3; }
This is too trivial.
Warning: variable declared but never used.
#StaticChecks
#StaticTypeChecks
#StaticTyping
vintage screwlisp account reshared this.
Digital Mark λ ☕️ 🕹 🙄
in reply to Vassil Nikolov • • •@smlckz @sektor @clew @eduardoochs
Anecdotal, but I almost never make the kinds of errors that type checking can find. I did make one a few weeks ago! I was very surprised, I'd passed an entirely wrong kind of object to a function. Once a year error. YMMV.
And yes, intentionally trivial example is trivial. Add
log("addints", x, y)
and now the type checker is a blind idiot again. You cannot make types enforce logic!
DougMerritt (log😅 = 💧log😄)
in reply to Digital Mark λ ☕️ 🕹 🙄 • • •@mdhughes
" You cannot make types enforce logic!"
Well hold on there, not so fast. You can in fact put *ALL* logic into a type system.
So you have to give a context for what you're talking about.
I agree that what you said is true of the most commonly used programming languages.
@vnikolov @screwtape @smlckz @sektor @clew @eduardoochs
Digital Mark λ ☕️ 🕹 🙄
in reply to DougMerritt (log😅 = 💧log😄) • • •@smlckz @sektor @clew @eduardoochs Kurt Gödel disagrees. The Halting Problem disagrees.
Programming languages are in a sense a "logic system", but they don't prove anything, just bash numbers around like a rock tumblr until you get some gravel out. Is it the gravel you wanted? They *cannot* know.
Even inductive tools like Prolog just apply rules you've given, they can't prove those rules are logically correct.
ûnkreativiteit
in reply to Digital Mark λ ☕️ 🕹 🙄 • • •@mdhughes @sektor @clew @eduardoochs Just as you said, type checkers, or static analysis tools in general, can decidable-y (decidedly? decisively? „entschieden“ perhaps) prove only those properties of programs that can be trivially derived from the program source code. en.m.wikipedia.org/wiki/Rice's… For the rest, there is no alternative to running the program to figure them out.
To make it 'trivial' for the analyzer, the programmers have to annotate the source code properly. You can see how it turned out for Rust with lifetime annotations.
theorem in computability theory
Contributors to Wikimedia projects (Wikimedia Foundation, Inc.)Vassil Nikolov
in reply to ûnkreativiteit • • •@smlckz @mdhughes @sektor @clew @eduardoochs
smlckz:
<">
type checkers, or static analysis tools in general, can decidable-y (...) prove only those properties of programs that can be trivially derived from the program source code.
</">
For a sufficiently large value of trivially¹.
But my thesis is that those properties are unproportionately important to engineering practice.
_________
¹ Yes, I am quite aware how some mathematicians and logicians use this word.
ûnkreativiteit
in reply to Vassil Nikolov • • •@mdhughes @sektor @clew @eduardoochs Sure.
> Sometimes a loss of precision is necessary to make the semantics decidable (see Rice's theorem and the halting problem). In general, there is a compromise to be made between the precision of the analysis and its decidability (computability), or tractability (computational cost).
From en.m.wikipedia.org/wiki/Abstra…
As for the practice, there's Symbolic execution: en.m.wikipedia.org/wiki/Symbol…
Technique for Program Analysis
Contributors to Wikimedia projects (Wikimedia Foundation, Inc.)ûnkreativiteit
in reply to ûnkreativiteit • • •Sensitive content
At this point, I'm wondering what is the proper.. etiquette for favoriting and boosting a post.. Is a favourite a way to indicate that the post was read, an acknowledgement, approval or agreement with the contents of the post? What threshold do you use to determine the boost-worthy-ness of a post? I'd like to know how it was originally intended and how it has turned out now.
vintage screwlisp account
in reply to ûnkreativiteit • • •Sensitive content
Ah, sorry. I favourite to indicate I've read a post. On the other hand, I'm boosting basically on the off chance it leads to other interesting things to read. I'm a bit sympathetic that a few of you were rather hoping to hear from Edrx today rather than later this month. 1/2
vintage screwlisp account
in reply to vintage screwlisp account • • •Sensitive content
@smlckz from my perspective, I'm also still trying to figure out type theory and programming and I would like to pursue this more usefully when we finally get Edrx.
From my perspective, a few interesting versions of typing came up today, somewhat traceable to that arguing-about-types-blog
- live dangerously, no typing
- ahead-of-time static typing for extreme safety
- static but implicit typing/the haskell people
- the odd double-headed nature of ansi cl types
vintage screwlisp account
in reply to vintage screwlisp account • • •Sensitive content
however, I am still struggling to get from results from type theory - and you, and Vassil, and dm are prone to sharing these, and programming as such. Like, lisp's method combination for example. Obviously today I babbled a bit about automatic theorem proving, but that's not exactly a result of type theory for something it seems like it should practically connect to like generic systems. Maybe I'm totally in the dark.
vintage screwlisp account
in reply to vintage screwlisp account • • •Sensitive content
@smlckz 4/2 (finishing my annoying stream of consciousness)
or we get to something like mdh's habit of type assertions at the front of functions in scheme ("when it's important") ( @mdhughes ). Maybe when I read one of these type theory for programmers books. We also heard today lisp's use of both (declare (foo bar)) and deftype foo... ctypecase x (foo .. is not shared by other languages in general. Further the optional requirement for declarations sits oddly.
Karsten Johansson
in reply to vintage screwlisp account • • •Sensitive content
I do the same. Sometimes I forget, but it's a way to acknowledge something where I've been @.
Especially if don't really have anything to add. Nicer than just leaving it dangling.
Otherwise, it's just acknowledging something I thought was interesting.
I boost things that I think some of my other followers might find interesting, but might miss if they aren't following the person who said whatever it was. I'm pretty minimalistic with the boosts, since I straddle a fence between common lisp and infosec folk.
ûnkreativiteit
in reply to vintage screwlisp account • • •Sensitive content
Vassil Nikolov
in reply to ûnkreativiteit • • •@smlckz @mdhughes @sektor @clew @eduardoochs
I wish I could answer at least semi-authoritatively.
I just favorited your post because:
These are good questions.
And I wanted it to leave a stronger trace in my timeline.
Digital Mark λ ☕️ 🕹 🙄
in reply to Vassil Nikolov • • •Karsten Johansson
in reply to Vassil Nikolov • • •Vassil Nikolov
in reply to Digital Mark λ ☕️ 🕹 🙄 • • •@mdhughes @smlckz @sektor @clew @eduardoochs
mdhughes:
<">
Kurt Gödel disagrees. The Halting Problem disagrees.
</">
Raising the stakes...
<">
... in a sense a "logic system", but they don't prove anything, just bash numbers around like a rock tumblr until you get some gravel out. Is it the gravel you wanted? They *cannot* know.
</">
For the record, I do believe this is only a part of the picture; the other parts are very significant, but alas, I can't elaborate now.
Vassil Nikolov
in reply to vintage screwlisp account • • •Or:
"Beware of using this algorithm.
I have only proved that it is correct, but I haven't tested it."
(Donald Knuth; possibly apocryphal)
vintage screwlisp account reshared this.
Vassil Nikolov
in reply to Digital Mark λ ☕️ 🕹 🙄 • • •@mdhughes @eduardoochs
I disagree.
Remember the old joke that cowboy taxi drivers stop at green lights?
Vassil Nikolov
in reply to vintage screwlisp account • • •@eduardoochs
screwtape> in languages that handle PARSE-INTEGERable strings /such as #javascript (#Kitten)/ is the equivalence (sometimes) of "1" and 1 an example of defeasible inheritance?
I don't know what defeasible inheritance is, but in JavaScript way too often this is a pain.
People even get into the habit of always writing things like (+x) instead of x...
I think this has already been elaborated.
vintage screwlisp account reshared this.
Vassil Nikolov
in reply to vintage screwlisp account • • •@eduardoochs
In spite of its name, `deftype' doesn't define a new type.
It defines a new name for an existing type.
#CommonLisp
vintage screwlisp account reshared this.
Karsten Johansson
in reply to Vassil Nikolov • • •@eduardoochs Yup, it is a compile-time alias. Kinda like a macro.
(deftype small-int ()
'(integer 0 100))
(typep x 'small-int)
(declare (type small-int x))
At compile time, becomes:
(typep x '(integer 0 100))
(declare (type (integer 0 100) x))
I think deftype is mostly useful for automagic documentation, and perhaps shorter statements. Defstruct is another way to do this, but might be overkill for this one-trick pony. Correct me if I'm wrong.
I don't think I've ever used it. Took me a few stabs to get something that worked as intended lol.
vintage screwlisp account
in reply to Karsten Johansson • • •Sensitive content
@ksaj
cs-user> (defun sometimes (x) (and (zerop (random 2)) x))
sometimes
cs-user> (deftype lucky-number () `(and number (satisfies sometimes)))
lucky-number
cs-user> (typecase 7
(lucky-number 'winner))
nil
cs-user> (typecase 7
(lucky-number 'winner))
nil
cs-user> (typecase 7
(lucky-number 'winner))
winner
at first, I thought my type wasn't working.
@vnikolov @dougmerritt @eduardoochs
Karsten Johansson
in reply to vintage screwlisp account • • •Sensitive content
@eduardoochs
lol that's kinda how my code usually runs first time around.
ûnkreativiteit
in reply to vintage screwlisp account • • •Sensitive content
vintage screwlisp account reshared this.
ûnkreativiteit
in reply to Vassil Nikolov • • •@eduardoochs
Here's the relevant theory to perhaps better understand this:
> Thus, in the simplest type systems, the question of whether two types are compatible reduces to that of whether they are equal (or equivalent). Different languages, however, have different criteria for when two type expressions are understood to denote the same type. These different equational theories of types vary widely, two extreme cases being structural type systems, in which any two types that describe values with the same structure are equivalent, and nominative type systems, in which no two syntactically distinct type expressions denote the same type (i.e., types must have the same "name" in order to be equal).
From en.m.wikipedia.org/wiki/Type_s… , section 'Compatibility: equivalence and subtyping'
This blog post explains this concept quite well: liamduckett.com/posts/structur…
And as for why we might need ''new'' types, have a look at how Nim handles it: nim-lang.org/docs/manual.html#…
Structural & Nominal Typing
Liam Duckett (liamduckett.com)akater
in reply to vintage screwlisp account • • •@vnikolov @dougmerritt @eduardoochs
Vassil Nikolov
in reply to akater • • •@akater @eduardoochs
akater> DEFSTRUCT does not necessarily DEFTYPE....
Quite.
In those cases it doesn't even define a new type, but something partly analogous to a view (in the database sense).
You might also think of those "defstructables" as relatives of abstract data types and with them it becomes much easier to switch later to a full-fledged dedicated type, if appropriate.
#CommonLisp
vintage screwlisp account
in reply to Vassil Nikolov • • •cs-user> (defstruct foo)
foo
cs-user> (typep #s(foo) 'foo)
t
obviously different to defclass
@eduardoochs @vnikolov @dougmerritt
akater
in reply to Vassil Nikolov • • •@eduardoochs @screwtape @dougmerritt
vintage screwlisp account
in reply to akater • • •given that the interview will be around the end of this month now, I will try to try eev mode in terms of cl-el
@eduardoochs @vnikolov @dougmerritt
akater
in reply to vintage screwlisp account • • •It looks heavily interactive; that won't fly. Keymaps are at their proto stage in cl-el, and only very basics of buffers work.
Also, cl-el currently struggles a lot with Emacs 28 and later. The roadmap is clear but it does take man-hours.
@eduardoochs @vnikolov @dougmerritt
vintage screwlisp account
in reply to akater • • •I guess so. Well, eek is exactly like doing keypresses in emacs. Which is exactly what we don't got, I guess.
@eduardoochs @vnikolov @dougmerritt
Eduardo Ochs
in reply to vintage screwlisp account • • •akater
in reply to Eduardo Ochs • • •@screwtape @vnikolov @dougmerritt
el.org · master · akater / cl-el · GitLab
GitLabEduardo Ochs
in reply to akater • • •Eduardo Ochs
in reply to Eduardo Ochs • • •anggtwu.net/2025-modern.html#0…
I don't think that it would be possible to do that in Common Lisp...
Some problems of modernizing Emacs (2025)
anggtwu.netDougMerritt (log😅 = 💧log😄)
in reply to Eduardo Ochs • • •@eduardoochs @akater
IMHO you can have a favorite to like without even justifying it, but it *is* interesting to see people's thinking.
I took a look. Couldn't we say that a lack of a canonical representation is simply a bug, regardless of whether it might be an arbitrary choice of multiple representations?
BTW since you're teaching, it makes perfect sense that you're thinking about the understanding of beginners.
I'm rusty in Common Lisp, and it's big, but I would hesitate to say that anything is impossible in CL -- there are a lot of smart people out there who point out (sometimes obscure) ways to do things.
In really old Lisps, things like print functions might be in a plist, property list, which I kind of liked but the community eventually did not. 😀
Artyom Bologov
in reply to DougMerritt (log😅 = 💧log😄) • • •@eduardoochs I might be missing your point, so feel free to ignore. What I think I got from your video and subtitles is that changes to more opaque and un-inspectable (word choice is deliberate, bear with me) structures hurts Elisp learnability. You're saying that your inspectable setup is hard to reproduce in Common Lisp, due to... abundance of (semi-opaque) types in CL standard library?
I disagree. In CL, there are
- INSPECT and DESCRIBE functions that allow peeking into the objects you have, be it functions or readtables or classes or whatever.
- Most types/classes have accessors and other functions allowing to see their state and get meta-info about them. For functions, there's function-lambda-expression, quite a powerhouse of function inspection, allowing to see the real name of the function object, whether it is a closure, and the exact expression bound to it (whenever accessible):
CL-USER? (defun foo (a b) (+ a b))
FOO
CL-USER/D1? (function-lambda-expression #'foo)
(EXT:LAMBDA-BLOCK FOO (A B) (DECLARE (SI::C-GLOBAL)) (+ A B))
NIL
FOO
- And then, with this abundance of accessors and presence of MetaObject Protocol, one (programmer) can inspect anything in the running image, at least programmatically. But then, one can also build inspectors to be used as REPL commands, separate REPLs, or even GUI inspectors (cliki.net/Clouseau) in a relatively portable way. My library for inspector building is github.com/aartaka/trivial-ins…, and I built my own inspector commands in my CL config here github.com/aartaka/lisp-config…
CL-USER/D1? :in #'foo
0 :self = #<bytecompiled-function foo 0x7bd3dfe5d910>
1 :id = 136149924698384
2 class-of = #<The built-in-class function>
3 type-of = compiled-function
4 :name = foo
5 :arguments = (a b)
6 compiled-function-p = t
7 :closure-p = nil
8 :expression = (ext:lambda-block foo (a b) (declare #) (+ a b))
9 lambda-list-keywords = (&optional &rest &key &allow-other-keys &aux ...)
10 call-arguments-limit = 65536
11 lambda-parameters-limit = 65536
- And I'm not even mentioning implementation-specific niceties, in particular SBCL ones. Just for the sake of this post, I ran these functions/commands above on ECL, a second? third? most popular implementation of CL (CC @jackdaniel), just to see how well it fares in terms of object inspection. And it's good!
Not sure if I got all your points, but here's my little something about CL 😉
@dougmerritt @akater @vnikolov @screwtape
GitHub - aartaka/trivial-inspect: A portable Common Lisp toolkit for building inspectors
GitHubEduardo Ochs
in reply to Artyom Bologov • • •@aartaka @jackdaniel @akater
Hey! Thanks! And: oh, no - did I say that? I hope not... but I'm travelling tomorrow to a conference, my presentation there is on tuesday, and it's only 50% ready...
I think that what I said was this. Emacs Lisp was so simple that people could understand it well very quickly even with a very primitive inspector; now it is becoming much more complex, and the people who are adding new data structures to it (a.k.a. Stefan Monnier...) don't care about the inspectors - they're leaving the work on the inspectors to other people, and they aren't even announcing explicitly where there is work needing to be done, so now we have an Emacs with several important-ish data structures that are very hard to inspect... one example is advice, that I only understood after several years. Also, now that are several CL-like features in Emacs that are badly documented and only partially implemented, and the best way to learn them is to learn them in Common Lisp first, and then re-learn them in Emacs...
Anyway, I haven't finished making that video yet! =) And I will try your suggestions ASAP, i.e., in a few days... thanks! =)
akater
in reply to Eduardo Ochs • • •Advices exist in Elisp since at least 1993, and they were part of other Lisp systems. CCL has built-in advices.
If something looked more simple, that doesn't mean it made sense. You apparently dislike the fact that symbol-function doesn't return a (lambda ..) list anymore. But symbol-function should return a function, not a list; it only makes sense and is less confusing, not more.
Besides, symbol-function working the way you describe wouldn't make any sense at all in a lexically scoped language. So, effectively you complain that Elisp has become more difficult to understand because it got lexical scope. And what would be your solution to that, exactly? (Your video lost me once you've decreased the font size.)
@jackdaniel @dougmerritt @vnikolov @screwtape
Eduardo Ochs
in reply to akater • • •@akater @jackdaniel
Btw/for the sake of completeness...
I didn't expect that anyone would watch the video on youtube...
When people watch it "with eev" they do something like this:
wget -nc anggtwu.net/eev-videos/2025-mo…
wget -N anggtwu.net/eev-videos/2025-mo…
mpv --fs --osd-level=2 2025-modern.mp4
Eduardo Ochs
in reply to akater • • •My solution (?) would be to keep both the old-style-Emacs lambdas - that are lists - and the Common-Lisp-style lambdas, that are other data structures that are not lists. But remember that I live in another planet - see anggtwu.net/emacsconf2024.html… - so for me it is important to keep the basic parts of Emacs Lisp easily understandable by some kinds of people that you don't know that they exist...
Emacs, eev, and Maxima - now! (eev @ EmacsConf 2024)
anggtwu.netEduardo Ochs
in reply to Eduardo Ochs • • •Also:
anggtwu.net/emacsconf2024.html…
Dropping or hiding the parts of Emacs Lisp that made it "learnable in a day" would increase the number of people who spend 5 years treating Emacs Lisp as a configuration language!!!!!!
Emacs, eev, and Maxima - now! (eev @ EmacsConf 2024)
anggtwu.netVassil Nikolov
in reply to Eduardo Ochs • • •@eduardoochs @akater @jackdaniel
As a sidenote, some parts of that presentation reminded me of:
"There is no royal road to geometry."
(Euclid?)
"There is no royal road to mathematics."
(d'Alembert to his pupil, a prince who asked for an easy solution suitable for someone of royal blood)
"There is no royal road to knowledge."
(Unknown)
Vassil Nikolov
in reply to Eduardo Ochs • • •@eduardoochs @akater @jackdaniel
After reading parts of that presentation, I think I understand better what you are looking for.
I don't think there is an easy solution and I am sure there isn't a one-size-fits-all solution (as in many other cases).
I know #CommonLisp quite well, so I don't have some of the problems you describe.
I use #Emacs and #Elisp quite substantially, but I don't participate in related discussion groups, so I don't know what is on people's minds.
DougMerritt (log😅 = 💧log😄)
in reply to akater • • •@akater
On just that one subject: pretty much all dynamic languages used to be dynamically scoped, and that was good for lots of things, but was eventually realized to be problematic, so various things got converted to lexical scope.
Generally we should just find alternate approaches that *do* work with lexical scoping.
@eduardoochs @jackdaniel @vnikolov @screwtape
ûnkreativiteit
in reply to Vassil Nikolov • • •Dodekalogue
wiki.tcl-lang.orgûnkreativiteit
in reply to vintage screwlisp account • • •What to know before debating type systems | Ovid [blogs.perl.org]
blogs.perl.orgvintage screwlisp account reshared this.
O SARILHO IS CROWDFUNDING ✨
in reply to vintage screwlisp account • • •vintage screwlisp account
in reply to O SARILHO IS CROWDFUNDING ✨ • • •@dougmerritt @vnikolov
O SARILHO IS CROWDFUNDING ✨
in reply to vintage screwlisp account • • •vintage screwlisp account reshared this.
ûnkreativiteit
in reply to vintage screwlisp account • • •And also this online book by @BartoszMilewski that explains category theory to programmers. bartoszmilewski.com/2014/10/28…
And this classic: fsharpforfunandprofit.com/post…
There are so many sequels, in different programming languages, of ''making illegal states unrepresentable.''
Category Theory for Programmers: The Preface
Bartosz Milewski's Programming Cafevintage screwlisp account reshared this.