• Frere_de_la_QuoteB
    link
    fedilink
    English
    arrow-up
    1
    ·
    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_numOPB
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year 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.