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.

https://anggtwu.net/math-b.html
https://www.hanselman.com/blog/stringly-typed-vs-strongly-typed
https://blogs.perl.org/users/ovid/2010/08/what-to-know-before-debating-type-systems.html
type links welcome

and #lisp

@shizamura possibly you can explain types of OWL to us instead of sleeping?

Eduardo Ochs - Academic Research - Categorical Semantics, Downcasing Types, Skeletons of Proofs, and a bit of Non-Standard Analysis

@screwtape 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...

@eduardoochs @screwtape
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: https://www.hanselman.com/blog/stringly-typed-vs-strongly-typed

@vnikolov

Stringly Typed vs Strongly Typed

I used to call this technique 'type tunnelling' and noted its use in XML in ...

@dougmerritt @eduardoochs @screwtape

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

@eduardoochs
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)

@vnikolov @dougmerritt
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

@vnikolov @dougmerritt
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

@screwtape @vnikolov @dougmerritt @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

@mdhughes
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

@screwtape @vnikolov @dougmerritt @eduardoochs Fantasy: Engine gives you awesome new information.

Reality: Fatal error: Type <T<Q:E>,D> unsatisfied at char 31,969.
#programming #types

@screwtape @mdhughes @dougmerritt @eduardoochs

It could, but it is a lot of work to make it happen and there is too little demand to justify that work.