News for hackers. Stuff that matters.

A comment on Why ML/OCaml are good for writing compilers (1998). Parent comment

Re:Why ML/OCaml are good for writing compilers (1998) by wtetzner on Sunday April 16, 2017 @12:59PM (#14126417)
> A disadvantage of pattern matching is that it's relatively easy to write a function where you define a variable and then first access it 500 lines later.

I've written plenty of OCaml, and I can't see how this would ever be a problem. Are you writing 500 line functions in OCaml? It seems like it would be difficult to write such a long function in OCaml. An why would pattern matching cause it?

Maybe I'm misunderstanding something.

[ Parent | on HN ]
Re:Why ML/OCaml are good for writing compilers (1998) by scythe on Monday April 17, 2017 @02:15PM (#14133143)
> Are you writing 500 line functions in OCaml? It seems like it would be difficult to write such a long function in OCaml.

Me, no; my colleagues, yes. I am averse to writing long functions even more than most people. I agree with 'jldugger that this is a sign that some cleanup is needed but the point is that bad code exists in cool languages too (there are also Mondays in Australia).

[ Parent | on HN ]
Re:Why ML/OCaml are good for writing compilers (1998) by jldugger on Sunday April 16, 2017 @02:19PM (#14126761)
I've done it when writing translators / compilers for school. If you're pattern matching against an AST, its easy to to have a pretty big list of possible types the AST can contain.

Probably this is a code smell that should be rearchitected.

[ Parent | on HN ]
Re:Why ML/OCaml are good for writing compilers (1998) by abhirag on Sunday April 16, 2017 @05:05PM (#14127503)
Haven't used OCaml but the recommended practice in Erlang/Elixir is to break down complex pattern matches into separate function clauses, as function calls are also driven by pattern matching.
[ Parent | on HN ]