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

F18 Fortran compiler and runtime project is accepted as part of LLVM project

lists.llvm.org

Post reply on HN
Print view View original

11–20 of 34 posts

Re: F18 Fortran compiler and runtime project is accepted as part of LLVM project

#11

Post by pjmlp »

TimTheTinker wrote: post #9
beezle wrote: post #5

Great news! Curious - are there any selfhosting Fortran compilers?

If a Fortran compiler were self-hosting, I might think twice before using it... I can't imagine implementing a parser/lexer in Fortran of all languages. Considering that loops and procedures are the main supported models of indirection/abstraction, I expect the defect rate per kLoC would be rather high. Edit: Looks like OOP support arrived in Fortran 2003. Does anyone know how much of a difference it made?

As the very first high level language, plenty of compilers were implemented in FORTRAN during the 60's.

Re: F18 Fortran compiler and runtime project is accepted as part of LLVM project

#12

Post by Nydhal »

GolDDranks wrote: post #10
codesushi42 wrote: post #3

Earlier quoted context omitted.

According to TIOBE, Fortran is more popular than Google's Dart and Mozilla's Rust. Not to mention Kotlin, Lisp, and Erlang.

Fortran used to be more popular. However, TIOBE is a lacking indicator, as stated here: http://pypl.github.io/PYPL.html (do a in-page-search with "Why is PYPL so different from TIOBE ?") Some other indicators such as Redmonk ( https://redmonk.com/sogrady/2019/03/20/language-rankings-1-1... ) show that both Dart and Rust are more popular than Fortran. (Although each of them have their own set of biases.)

I think you mean lagging indicator.

Re: F18 Fortran compiler and runtime project is accepted as part of LLVM project

#14

Post by yiyus »

TimTheTinker wrote: post #9
beezle wrote: post #5

Great news! Curious - are there any selfhosting Fortran compilers?

If a Fortran compiler were self-hosting, I might think twice before using it... I can't imagine implementing a parser/lexer in Fortran of all languages. Considering that loops and procedures are the main supported models of indirection/abstraction, I expect the defect rate per kLoC would be rather high. Edit: Looks like OOP support arrived in Fortran 2003. Does anyone know how much of a difference it made?

Fortran has evolved a lot. You can practically use any programming paradigm with it. If you chose well a subset of all its features, you can actually write quite elegant code. I have never used it for this and do not have any example, but I would not expect it to be particularly worse than any other language.

Re: F18 Fortran compiler and runtime project is accepted as part of LLVM project

#15

Post by sampo »

TimTheTinker wrote: post #9
beezle wrote: post #5

Great news! Curious - are there any selfhosting Fortran compilers?

If a Fortran compiler were self-hosting, I might think twice before using it... I can't imagine implementing a parser/lexer in Fortran of all languages. Considering that loops and procedures are the main supported models of indirection/abstraction, I expect the defect rate per kLoC would be rather high. Edit: Looks like OOP support arrived in Fortran 2003. Does anyone know how much of a difference it made?

> Considering that loops and procedures are the main supported models of indirection/abstraction

What does this mean, and how is this any different from e.g. C?

Re: F18 Fortran compiler and runtime project is accepted as part of LLVM project

#16

Post by jeyemhex »

TimTheTinker wrote: post #9
beezle wrote: post #5

Great news! Curious - are there any selfhosting Fortran compilers?

If a Fortran compiler were self-hosting, I might think twice before using it... I can't imagine implementing a parser/lexer in Fortran of all languages. Considering that loops and procedures are the main supported models of indirection/abstraction, I expect the defect rate per kLoC would be rather high. Edit: Looks like OOP support arrived in Fortran 2003. Does anyone know how much of a difference it made?

From the use-cases I've seen, OOP didn't make a massive difference. Many of the ideas from OOP were possible before, e.g. abstraction with modules and derived types (essentially C structs) from Fortran 90/95. Others, like polymorphism felt a bit bolted on and haven't gained widespread usage.

As for a self-hosting compiler, I'm not aware of one, although it's something I'd be interested in having a go at. I've written a regex engine in Fortran before, I just haven't had the time to sit down with the Fortran standard and a textbook on compiler design (I'm a physicist by trait, so I've not been taught this stuff formally).

Re: F18 Fortran compiler and runtime project is accepted as part of LLVM project

#17

Post by mikorym »

For those that don't know:

'The LLVM compiler infrastructure project is a "collection of modular and reusable compiler and toolchain technologies" used to develop compiler front ends and back ends.

LLVM is written in C++ and is designed for compile-time, link-time, run-time, and "idle-time" optimization of programs written in arbitrary programming languages.'[1]

[1] https://en.wikipedia.org/wiki/LLVM

Re: F18 Fortran compiler and runtime project is accepted as part of LLVM project

#18

Post by wycy »

I write code in modern Fortran 2018, making extensive use of the new language features, so this is welcome news. I use Intel Fortran Compiler 2019 at work and gfortran-8 at home.

Modern Fortran looks completely different from the old school FORTRAN77 that most people envision when thinking of Fortran. For reference, I did this past year's Advent of Code contest all in Fortran[0].

[0] https://gitlab.com/bwearley/advent-of-code-2018/tree/master

Re: F18 Fortran compiler and runtime project is accepted as part of LLVM project

#19

Post by dmitryminkovsky »

sampo wrote: post #15
TimTheTinker wrote: post #9

Earlier quoted context omitted.

If a Fortran compiler were self-hosting, I might think twice before using it... I can't imagine implementing a parser/lexer in Fortran of all languages. Considering that loops and procedures are the main supported models of indirection/abstraction, I expect the defect rate per kLoC would be rather high. Edit: Looks like OOP support arrived in Fortran 2003. Does anyone know how much of a difference it made?

> Considering that loops and procedures are the main supported models of indirection/abstraction What does this mean, and how is this any different from e.g. C?

I’m guessing your parent comment is thinking along the lines of https://news.ycombinator.com/item?id=14123100

Re: F18 Fortran compiler and runtime project is accepted as part of LLVM project

#20

Post by rbanffy »

Nydhal wrote: post #12
GolDDranks wrote: post #10

Earlier quoted context omitted.

Fortran used to be more popular. However, TIOBE is a lacking indicator, as stated here: http://pypl.github.io/PYPL.html (do a in-page-search with "Why is PYPL so different from TIOBE ?") Some other indicators such as Redmonk ( https://redmonk.com/sogrady/2019/03/20/language-rankings-1-1... ) show that both Dart and Rust are more popular than Fortran. (Although each of them have their own set of biases.)

I think you mean lagging indicator.

Any sufficiently lagging indicator is also a lacking indicator.
Post reply on HN