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
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
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.
Thank you,