Re: Bison 3.8.1 released with D backend
On Wednesday, 15 September 2021 at 14:48:06 UTC, Tejas wrote: I'm sorry for being ignorant, but what does it mean to have a \ back-end in Bison? Does it mean that the parser program that `Bison` will output will be a `.d` file? Assuming I'm correct: What does it matter whether the parser is a `.c .cpp .d .pl` or whatever file? I'm really sorry I'm coming off as abrasive/ungrateful. I have no intention to belittle the author or the work she has done. But I'm really curious: What changes if `Bison` outputs it's parser in some language other than the one it originally targeted(perhaps that was C?) I'm really sorry if this appears dismissive, I just don't know how to phrase it any better. A question asking for its author to be educated would be more suitably posted in the Learn forum.
Re: Bison 3.8.1 released with D backend
Quote: *** A skeleton for the D programming language The "lalr1.d" skeleton is now officially part of Bison. It was originally contributed by Oliver Mangold, based on Paolo Bonzini's lalr1.java, and was improved by H. S. Teoh. Adela Vais then took over maintenance and invested a lot of efforts to complete, test and document it. It now supports all the bells and whistles of the other deterministic parsers, which include: pull/push interfaces, verbose and custom error messages, lookahead correction, token constructors, internationalization, locations, printers, token and symbol prefixes, etc. Two examples demonstrate the D parsers: a basic one (examples/d/simple), and an advanced one (examples/d/calc).
Bison 3.8.1 released with D backend
The D back-end for deterministic parsers contributed by Adela Vais is now available with the release of Bison 3.8.1 ! https://github.com/adelavais See https://savannah.gnu.org/forum/forum.php?forum_id=10047 for details.
Re: Reading IDX Files in D, an introduction to compile time programming
On Saturday, 22 August 2020 at 07:04:19 UTC, Petar Kirov
[ZombineDev] wrote:
I feel like limiting CTFE just gives a false sense of security
and destroys many interesting use cases. If a part of my build
system will do directory traversal to build the list of files
to import, what difference would it make to not have this as a
single build step. The argument that somehow
dmd -run gen_code.d | dmd -
Is more secure than just:
dmd file.d # file.d is allowed to access the FS at CT
makes no sense to me.
See Jai for example. You can run absolutely *any* code at
compile time. 5 years ago Jai's creator made a demo of running
an OpenGL game at CT [1]. In the same demo he also used CTFE to
validate calls to printf. He made the case that while many
compilers go the route of hard-coding checks for printf style
functions in the compiler, he thinks that users should be able
to implement arbitrary checks in their code. And 5 years later,
instead of D expanding the frontiers of what's possible via
CTFE, printf checking was hard coded in the compiler [2].
[1]: https://www.youtube.com/watch?v=UTqZNujQOlA
[2]: https://github.com/dlang/dmd/pull/10812/files
I don't need say that unlimited CTFE has been a huge success
for Jai. What I wish is that we can learn from this stop
bringing arguments that C people would bring for D's CTFE ("My
Makefile calls a Python script to generate C code and it's
doing just fine, so I don't think one should be allowed to run
code at compile time, as it will make the code just harder to
follow").
As another example, types in Zig are first class citizens [3]
and can be manipulated with CTFE just like any other value.
"Type functions" in D should just be regular D functions taking
types as parameters and returning types.
[3]:
https://ziglang.org/documentation/master/#Introducing-the-Compile-Time-Concept
Strongly Agreed!
Re: GCC 10.1 Released
On Saturday, 16 May 2020 at 00:26:31 UTC, Carl Sturtivant wrote: On Thursday, 14 May 2020 at 16:57:20 UTC, Iain Buclaw wrote: [[GCC 11 Development]] Now the development cycle has started again, I have ambitions for a number disruptive changes to land during the next release cycle. Superb! --- gdc is perhaps the most important strategically and I am so glad to see this playing out. In fact I would like to characterize compiler progress for D as follows. dmd --- logistical progress ldc --- tactical progress gdc --- strategic progress :)
Re: GCC 10.1 Released
On Thursday, 14 May 2020 at 16:57:20 UTC, Iain Buclaw wrote: [[GCC 11 Development]] Now the development cycle has started again, I have ambitions for a number disruptive changes to land during the next release cycle. Superb! --- gdc is perhaps the most important strategically and I am so glad to see this playing out.
Re: Top Five World’s Most Underrated Programming Languages
On Monday, 14 January 2019 at 20:21:25 UTC, Andrei Alexandrescu wrote: Of possible interest: https://www.technotification.com/2019/01/most-underrated-programming-languages.html What's interesting here is the language nim, which perhaps has some lessons for D. https://nim-lang.org/
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Monday, 12 November 2018 at 10:05:09 UTC, Jonathan M Davis wrote: *sigh* Well, I guess that's the core issue right there. A lot of us would strongly disagree with the idea that bool is an integral type and consider code that treats it as such as inviting bugs. We _want_ bool to be considered as being completely distinct from integer types. The fact that you can ever pass 0 or 1 to a function that accepts bool without a cast is a problem in and of itself. But it doesn't really surprise me that Walter doesn't agree on that point, since he's never agreed on that point, though I was hoping that this DIP was convincing enough, and its failure is certainly disappointing. I'm at a loss to see any significant advantage to having bool as a part of the language itself if it isn't deliberately isolated from `integral types`.
