Live data from Hacker News

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

lists.llvm.org

21–30 of 34 posts

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

#21
post #11

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?

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

I'm not sure people used HLLs to write compilers at that time.

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

#22
post #21
post #11

Earlier quoted context omitted.

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

I'm not sure people used HLLs to write compilers at that time.

You just need to search for papers, quite a few available.

In fact, during the 60's Algol variants were already being used to write compilers and OSes.

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

#23
post #21
post #11

Earlier quoted context omitted.

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

I'm not sure people used HLLs to write compilers at that time.

I'm sure they did. I'd even expect most compilers were written in a HLL. Note that most refers to quantity: I expect most compilers were written as an academic exercise with no real intent to be used in production. I would expect the compilers that were intended for people to use to write production code were written in assembler because at the time compiler optimizations where not very good; computers were slow and expensive; and programmers were cheap: as such it would be worth the extra cost to write your compiler in a low level language.

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

#24
post #18

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/adven…

Yep, it even supports generics, go figure (pun intended).

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

#25
post #12

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.

While the page they link to uses "lagging", "lacking" actually seems to fit better with the context it's used in there:

The paragraph it's used in ("Why is PYPL so different from TIOBE ?") seems to argue that TIOBE is lacking, not lagging.

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

#26
post #6

Earlier quoted context omitted.

LLVM, like a lot of compilers, tries not to require the latest version of itself to bootstrap. See https://llvm.org/docs/GettingStarted.html#host-c-toolchain-b... GCC is similar.

They should still be able to CI it on the min version that does work. Eventually c++'17 will be old enough, so definitely the thing to do is just wait.

LLVM supports old platforms: some CI bots are targeting stable Debian, or Ubuntu 14.04.

LLVM is currently moving to C++14, which is a pain for some users like TensorFlow for instance which supports Ubuntu 14.04: the c++ standard library is too old. There are technical solutions for everything but for a component like LLVM, not pressuring its users into convoluted workflow is important.

Of course the LLVM developpers would love to just use the latest version of the standard all the time. For the library part of the standard, it is worked around by having its own: https://github.com/llvm/llvm-project/blob/master/llvm/includ... (and others in the same directory)

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

#27
post #26

Earlier quoted context omitted.

They should still be able to CI it on the min version that does work. Eventually c++'17 will be old enough, so definitely the thing to do is just wait.

LLVM supports old platforms: some CI bots are targeting stable Debian, or Ubuntu 14.04. LLVM is currently moving to C++14, which is a pain for some users like TensorFlow for instance which supports Ubuntu 14.04: the c++ standard library is too old. There are technical solutions for everything but for a component like LLVM, not pressuring its users into convoluted workflow is important. Of course the LLVM developpers…

The bootstrapping policy and the capabilities of the CI infra should be decoupled. I'm not not arguing the the policy.

In three years when LLVM bumps to C++'17 or whatever, then flang starts obeying.

But also I personally think is fine for parts of the project not needed to build C++ to use newer C++. Just use the newly built clang to build flang!

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

#28
post #5

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

I'm not sure that makes much sense;forth is typically a thin layer over a machine (historically physical, but also a VM, like the jvm) - so it'd generally make sense to implement the "compiler" is "assembler" (whatever that means for a given "machine")?

A forth in forth that is a cross compiler or something, doesn't quite "feel" like a forth system?

See also: https://www.forth.com/starting-forth/11-forth-compiler-defin...

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

#29
post #28
post #5

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

I'm not sure that makes much sense;forth is typically a thin layer over a machine (historically physical, but also a VM, like the jvm) - so it'd generally make sense to implement the "compiler" is "assembler" (whatever that means for a given "machine")? A forth in forth that is a cross compiler or something, doesn't quite "feel" like a forth system? See also: https://www.forth.com/starting-forth/11-forth-compiler-def…

The article is about Fortran, not Forth.

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

#30
post #18

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/adven…

I always feel that Fortran is under-represented on the benchmarks game, so let me take the opportunity to say fyi that we are usually happy to accept better programs.

If you wish to contribute a program then please follow these instructions:

https://salsa.debian.org/benchmarksgame-team/benchmarksgame/...

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Post reply on HN