• Trevoke@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months 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.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago

    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.

  • theangeryemacsshibe@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago

    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.

  • Frere_de_la_Quote@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    9 months 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.topOPB
    link
    fedilink
    English
    arrow-up
    1
    ·
    9 months ago

    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.topB
      link
      fedilink
      English
      arrow-up
      1
      ·
      9 months ago

      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.