this post was submitted on 27 Nov 2023
1 points (100.0% liked)

Lisp

53 readers
3 users here now

founded 1 year ago
MODERATORS
 

I would appreciate it if you could teach me about type inference in Lisp. Type Inference in Lisp. Weaknesses of Dynamically Typed… | by Kenichi Sasagawa | Oct, 2023 | Medium

top 9 comments
sorted by: hot top controversial new old
[–] Trevoke@alien.top 1 points 1 year ago

What is it that you want to learn about it, and what question do you have that the article does not answer?

[–] KaranasToll@alien.top 1 points 1 year ago (1 children)

Aren't you the one who wrote the article? I'm curious does islisp have generic functions like common Lisp? Does it have a type describing said generic functions? Does your type inferencer, infer generic function types?

I tried to read the code, but I find it quite difficult to follow.

[–] raevnos@alien.top 1 points 11 months ago

Yeah, they're very similar to CL's generics from what I've seen.

https://nenbutsu.github.io/ISLispHyperDraft/islisp-v23.html#generic_functions

[–] theangeryemacsshibe@alien.top 1 points 1 year ago (1 children)

In statically typed languages, you would have to predefine the output type. Such a function as bar couldn't be written.

Make a better type system - number -> (nil | number) should do the trick to type bar. SBCL can infer that one.

[–] sym_num@alien.top 1 points 1 year ago
[–] Frere_de_la_Quote@alien.top 1 points 1 year ago

This is a very complex problem. Maybe this will have some interest for you:

https://github.com/naver/lispe/wiki/6.1-Pattern-Functions

Here is how fizzbuzz is implemented:

; check if the rest of v/d is 0
(defun checkmod (v d) (eq (% v d) 0))

; if the element can be divided by 15 we return fizzbuzz
(defpat fizzbuzz ( [integer_ (not (% x 15))] ) 'fizzbuzz)

; if the element can be divided by 3 we return fizz
(defpat fizzbuzz ( [integer_ (checkmod x 3)] ) 'fizz)

; if the element can be divided by 5 we return buzz
(defpat fizzbuzz ( [integer_ (checkmod x 5)] ) 'buzz)

; rollback function, no type, we return x
; This function will only be called, if none of the above did apply
(defpat fizzbuzz (x) x)

; we apply 'fizzbuzz' to the first 100 elements.
; The argument type is: integer_

(mapcar 'fizzbuzz (range 1 100 1))
[–] sym_num@alien.top 1 points 11 months ago (1 children)

It seems that the intention behind the post wasn't communicated effectively. Let me provide some additional explanation. I've been interested in type inference for some time now.

Lisp is a dynamically typed language, allowing for a more casual approach to programming. However, there's a possibility of bugs remaining undetected until the testing phase.

Static typed languages perform type checking, preventing errors due to code that hasn't been executed. However, they can feel restrictive.

I'm exploring the possibility of incorporating both of these qualities within Lisp. It appears that there hasn't been much progress in terms of type inference within Lisp. Originally, Lisp wasn't designed with type inference in mind.

Utilizing type inference requires some ingenuity. I posted seeking opinions from those interested in type inference to gather insights and opportunities to further develop my thoughts.

[–] corbasai@alien.top 1 points 11 months ago (1 children)

As I understand current movement in Racket, PyPy or JS, them use self interpreter as knowledge machine at first run|trace. Code that executed once newer be optimized. Only parts of code which frequently executed (a.k.a 'hotspots) undergoes optimization steps. Which one should be specialization (selection|substitution) of procedures with well defined argument | return type signatures exactly. Static type inference as thing we have well defined in strong typed langs, for example in OCaml. Inference as process in Lisp may be special form of EVAL.

[–] sym_num@alien.top 1 points 11 months ago