Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lisk — Lisp and Haskell

chrisdone.com

Post reply on HN
Print view View original

21–30 of 30 posts

Re: Lisk — Lisp and Haskell

#21

Post by kwantam »

How strange. I was just thinking about doing this as a toy project earlier today.

I honestly don't share the OP's hatred of Haskell syntax, nor do I find it categorically worse than lispish languages. It's entertaining that he's gone from capital letters to the sigils (":"). Both tend to be controversial and which is better is more a matter of personal taste than anything.

I agree with another commenter that the lack of pattern matching syntax is something of a deficiency, and I was also troubled over how I'd do this. A "plambda" operator is one possibility that I was considering, though it feels like it's a really hackey embedding of MLish in lispish:

     (plambda fname
              ((pattern-1a pattern-1b ...) (stuff))
              ((pattern-2a pattern-2b ...) (stuff)))
Also, rather than a preprocessor I was thinking of implementing the whole thing in Template Haskell---not because it's easier, but really because I expect the opposite: I figured it'd be a good way to really bite off a big chunk of TH and get good at it.

EDIT: It occurs to me that one could just use a variant on cond to implement pattern matching, e.g., "cond-argv":

     (define (fname a b) (cond-argv
                         ((a1 b1) (stuff))
                         ((a2 b2) (stuff))))

Re: Lisk — Lisp and Haskell

#22

Post by kwantam »

omegazero wrote: post #16

I don't see how it's tackling the 'where' block--or it that would even be possible under this scheme. I find that my code is much more legible with the housekeeping and other less important helper-functions defined after the important bits. The clunky code that the author complains about can be much improved using where clauses to break it into chunks. Taking the authors example and moving some of the processing to a…

Well, brace and semicolon is considered "not idiomatic," though of course lisk as an alternative is even less so.

Regarding "where," it seems like most of the time "let" is an acceptable substitute. "where" is most convenient in conjunction with pattern matching syntax, so perhaps the solution to the problem of where and pattern matches can be neatly handled together.

Re: Lisk — Lisp and Haskell

#23

Post by kenjackson »

Here's my obligatory dumb question of the day. What is the problem he is trying to solve with the macros? It seems super straightforward, so I suspect I'm missing something (being only conversational in Lisp and Haskell, although don't know macros even decently):

Here's the snippet of code that describes the problem (which I don't get):

do exists <- doesFileExist "lalala" if exists then ... else ...

Re: Lisk — Lisp and Haskell

#24

Post by vorg »

Everyone has their own syntactic preferences. And what, really, is the difference between a preference for certain colors in an IDE and a preference for a certain syntax? Why is one easily customizable and the other rigidly defined by a language? If programs in all languages were stored on file as lisp-style AST's, with comments attached to AST nodes, then programmers could view programs using their own preferred syntax, as well as formatting and colors.

Re: Lisk — Lisp and Haskell

#25

Post by blasdel »

vorg wrote: post #24

Everyone has their own syntactic preferences. And what, really, is the difference between a preference for certain colors in an IDE and a preference for a certain syntax? Why is one easily customizable and the other rigidly defined by a language? If programs in all languages were stored on file as lisp-style AST's, with comments attached to AST nodes, then programmers could view programs using their own preferred syn…

The pure version of this idea has failed repeatedly for more than 50 years — noone ever writes their code in M-expressions :)

A debased version of the idea found success in Haskell, where the language syntax is defined as desugaring transformations towards a core calculus, but the internal representation is implementation-specific, and since the syntax was decided up front nobody got invested in writing code in a plain System F.

A novel take on the idea is implemented wholeheartedly in Google's Go, where there's a utility based on the compiler called gofmt that reserializes the AST. They use it not only for style issues, but also to update the entire standard library to reflect syntax changes.

Re: Lisk — Lisp and Haskell

#26

Post by vegai »

partition wrote: post #17

While programming in Haskell I also struggled with Haskell's brand of whitespace indentation, even though I come from Python. The key difference in usability between Python's whitespace indentation system and Haskell's indentation system is that you cannot start the lines in a block on the same line as the block. Python's is more restrictive: you must skip a line before starting a multi-line indented block; i.e., thi…

Also, the colon in python's syntax is one of its most important and often disregarded features. It gives such a simple and efficient cue that a new block is.

Re: Lisk — Lisp and Haskell

#27

Post by eru »

Periodic wrote: post #20
partition wrote: post #17

While programming in Haskell I also struggled with Haskell's brand of whitespace indentation, even though I come from Python. The key difference in usability between Python's whitespace indentation system and Haskell's indentation system is that you cannot start the lines in a block on the same line as the block. Python's is more restrictive: you must skip a line before starting a multi-line indented block; i.e., thi…

My rule has been to just pad "do" appropriately. Almost everything else works out well with a 4-space tab. Also, don't ever use only one-or-two spaces for indentation, and if you're finding you have a long expression with so much indentation and unindentation that it gets confusing I usually find I'm doing something confusing and should simplify it anyway. For example: let x = y in do something something with ( lots…

Yes, but like in Lisp, your Haskell code looks usually better without trailing parens.

Re: Lisk — Lisp and Haskell

#28

Post by rchowe »

kenjackson wrote: post #23

Here's my obligatory dumb question of the day. What is the problem he is trying to solve with the macros? It seems super straightforward, so I suspect I'm missing something (being only conversational in Lisp and Haskell, although don't know macros even decently): Here's the snippet of code that describes the problem (which I don't get): do exists <- doesFileExist "lalala" if exists then ... else ...

I don't know, what he seems to want to do can be expressed in haskell as

    doesFileExist "file" >>= \exists -> if exists
        then ...
        else ...
When he writes (do (>>= ... in his lisp example I don't think that he understands that do is just syntactic sugar for >>=s and >>s, and that what's actually happening is the data is being "taken out" (for lack of a better term) of a monad.

His problem seems to be that you do have to bother with monadic IO when with a macro he can just write (mif cond ...) and be done with it.

Re: Lisk — Lisp and Haskell

#29

Post by anc2020 »

Bit of a plug, I've written something like this except that it doesn't work via GHC and instead outputs source code (which means the gensyms aren't very safe...)

I'm not working on it anymore (unfortunately never really got over the static typing) but it should run and might be of interest: https://github.com/aliclark/hasp http://www-student.cs.york.ac.uk/~anc505/code/hasp/hasp.html

Re: Lisk — Lisp and Haskell

#30

Post by chrisdone »

omegazero wrote: post #16

I don't see how it's tackling the 'where' block--or it that would even be possible under this scheme. I find that my code is much more legible with the housekeeping and other less important helper-functions defined after the important bits. The clunky code that the author complains about can be much improved using where clauses to break it into chunks. Taking the authors example and moving some of the processing to a…

I forgot to mention that I will be including where; it's one of my favourite things about Haskell! (* 2 (x (where (= x 1))) will be rewritten to 2 * (let x = 1 in x).
Post reply on HN