Re: Compile time check for GC?

2021-01-27 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Wednesday, 27 January 2021 at 20:21:02 UTC, Kagamin wrote:
You can define a symbol that will conflict with GC and prevent 
linking with it.


That was an interesting thought! Maybe that could be a first step.

It didn't occur to me that I could sabotage the usage of GC. :-D



Re: Compile time check for GC?

2021-01-26 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
On Tuesday, 26 January 2021 at 16:08:15 UTC, Steven Schveighoffer 
wrote:

std.traits.hasAliasing?


I guess, but it will limit me too much. I should accept Element 
types that manage their own memory and has pointers to sub-ojects 
that don't point to GC memory. But I guess that would require a 
language extension or I would have to establish my own protocol 
(basically some enum I can test for, I guesss).



enough. One can compile a betterC library using your code, 
which is then used by a GC-allocating app, which means your 
library is told betterC is in use while compiling the template, 
but the GC is still involved.


So there doesn't seem to be a way to be sure that a pointer is 
not a GC pointer.


:-/



Re: Compile time check for GC?

2021-01-26 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
On Tuesday, 26 January 2021 at 15:30:09 UTC, Steven Schveighoffer 
wrote:
The only way to ensure the GC isn't used is with betterC. Even 
with @nogc tag on main, the GC could be used in static ctors, 
and casting function pointers/etc.


Yes, @nogc is not strong enough... It is for a container library, 
so maybe I could put test for the properties of the elements 
instead?


I guess I would want test if the Element type contains a pointer 
that should be traced by the GC.


But how would I go about it?

And this will only apply to templates, not to compiled code, 
since compiled code already is done (and one can obviously use 
betterC compiled code in normal D code).


Yes, but templates is ok, but I think Better_C is too restrictive 
in the long term. So I hope there is some way for my library to 
figure out if it has to care about GC for the template parameters 
the user provides.


I guess I also will find the equivalent of C++ 
std::trivially_copyable, std::trivially_destructible in Phobos, 
to figure out if memcpy is safe.





Compile time check for GC?

2021-01-26 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
Is there some way for library authors to test whether a GC is 
present at compile time? @nogc just means that my code does not 
depend on a GC, but it doesn't tell the compiler that my code is 
incompatible with GC.


I want to compute pointers in a way that is not scannable by a 
conservative collector for performance reasons. So I need to make 
sure that the faster code isn't chosen when people use GC using 
"static if"s.






Re: Why many programmers don't like GC?

2021-01-19 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Tuesday, 19 January 2021 at 13:41:33 UTC, ddcovery wrote:
(so I really don't understand your somewhat over-acted 
answer... maybe I need to read all the threads to understand 
your discomfort. In any case, accept my forgiveness if I have 
been able to bother you).


Forgot to answer, maybe I misinterpreted your statement, if so I 
apologise.  I felt you were putting too much emphasis on tooling 
as the dominant issue. If that becomes an excuse to not make som 
hard choices then we cannot move. Because everybody has to be on 
board for D to take a decisive direction. So, yes, I am not happy 
if we establish excuses as valid arguments against change!


I also don't think tooling or libraries are the core issues.  I 
think a solid language and a solid runtime is sufficient to get 
the ball rolling, because then you can retain those highly 
skilled people that will build the tools (over time). If people 
do not stay for a long time then you will have 50% of a tool 
built, then it goes into the graveyard. Then another builds 
another 50% solution, then it goes into the graveyard... D has a 
very large graveyard at this point of very interesting projects 
that only got to the 50-80% mark... then the authors left.


Anyway, commercial quality tooling is expensive. Even Google gave 
up on building their own IDE for Dart and left it to JetBrains.




Re: Why many programmers don't like GC?

2021-01-19 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Tuesday, 19 January 2021 at 13:41:33 UTC, ddcovery wrote:
That you want GC to work efficiently seems great to me... but 
at least we agree that D memory management is (and must be) GC 
based (so I really don't understand your somewhat over-acted 
answer... maybe I need to read all the threads to understand 
your discomfort. In any case, accept my forgiveness if I have 
been able to bother you).


I think we need to understand the landscape around us. What was 
possible development directions for D 2-5 years ago are now less 
viable, because it is now a game of (forever) catching up to the 
other ones (C++/Rust) rather than being something different. 5 
years ago I would argued more for competing with C++/Rust 
head-to-head. I think that train has left the station. D is on a 
different track now.


So the possible viable directions has shrunk to improving the GC 
(by some minor language adjustments), switching to ARC or some 
other paradigm that give roughly the same programming experience 
as D users are accustomed to.



Regarding the experience, do we really have to go into that? In 
this forum there are more or less many people with university 
level and between 10 and 30 years of experience ...


Yes, but would most of those have chosen D over Rust, Zig, Nim, 
C++20 today? We cannot know for sure, but there is clearly a 
significant uptake for competing languages that did not exist 10 
years ago.


So the "recruiting pool" is shrinking, that means losses (people 
leaving) cost even more today than 10 years ago...


So yes, we should absolutely listen to concerns from experienced 
developers with Comp.Sci. background if they chose to share them 
here in the forums. Tooling is a much bigger issue, but 
language/runtime adjustments are possible if we are willing to 
take some inconvenience in transition (some breakage).



In my case, for example, I have not worked manually with memory 
for decades (the 90s are a long way off, and my years with


Yes, I don't think most people want to work manually with memory, 
which is why mix-and-match is not sitting well. People who really 
want to do fully manual stick to C (they don't even want C++, 
right?).


Anyway, the more cores CPUs get, the more unacceptable blocking 
threads gets.


But I also suspect thread-pooling will eventually become the only 
reasonable option as one has to support CPUs with 2-30 cores... 
difficult to do that with a threading model. So, there are 
many... issues. Maybe threading is not the best model... Not sure.






Re: Why many programmers don't like GC?

2021-01-19 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
On Tuesday, 19 January 2021 at 10:43:45 UTC, Ola Fosheim Grøstad 
wrote:

On Tuesday, 19 January 2021 at 10:36:13 UTC, ddcovery wrote:
GC if D is not enough for you), but think about the thousands 
of experienced developers that where looking for something 
mature to work with and found that D was not an option.


And that's the point. The vast majority of _experienced_ 
developers recognize the current GC for what it is: a very 
basic primitive Boehm-style GC. Which basically is a trip back 
to the 1990s (or 1970s, whenever they started programming).


And if it isn't clear: stuff like that (and bugs in the type 
system) is what makes _experienced_ developers do exactly what 
you said. They do go to Rust, Go and C++ (or Nim or Zig).


Go back through the forums and you see plenty of dedicated D 
users that did exactly that.


Lost opportunities.

And that is why you don't get the eco system you think is needed.

Truly _experienced_ programmers do test a new language before 
they commit to it. They will recognize the flaws based on prior 
experience. They do know what typical flaws in language design 
look like. They have experience with maybe 5-15 languages, so you 
cannot just throw stupid slogans in their face, they are used to 
that too.




Re: Why many programmers don't like GC?

2021-01-19 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Tuesday, 19 January 2021 at 10:36:13 UTC, ddcovery wrote:
GC if D is not enough for you), but think about the thousands 
of experienced developers that where looking for something 
mature to work with and found that D was not an option.


And that's the point. The vast majority of _experienced_ 
developers recognize the current GC for what it is: a very basic 
primitive Boehm-style GC. Which basically is a trip back to the 
1990s (or 1970s, whenever they started programming).





Re: Why many programmers don't like GC?

2021-01-19 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Tuesday, 19 January 2021 at 06:14:52 UTC, Imperatorn wrote:
What adjustments to the language would be needed in your 
opinion?


I've mentioned them in connection with various approaches I've 
suggested. Depends on what area you want to improve.


In short (off the top of my head, maybe more is needed):

Precise tracing:

- The compiler currently cannot know what a tracing pointer 
points to: unions, casts.


- The GC traces many paths that never leads to ownership. 
Non-tracing pointer needed.


ARC:

- There is no knowledge of ownership, so ARC cannot be added. 
Compiler needs to know.


Singled threaded GC:

- The compiler does not know when a thread is created? So what 
are shared semantics?






Re: Why many programmers don't like GC?

2021-01-18 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Monday, 18 January 2021 at 15:18:40 UTC, aberba wrote:
1). You're not a minority at all. System programming is also 
vast so having a GC (especially D's special kind of GC) is 
nothing alien in System programming. If you look out there,


This is not true, and you know it.

There is nothing special about D's GC. It is just very basic.

GC is not usual in system level programming. Not at all usual. It 
happens, but it is not the usual.





Re: Why many programmers don't like GC?

2021-01-18 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Monday, 18 January 2021 at 13:14:16 UTC, Arafel wrote:
I must be in the minority here because one of the reasons why I 
started using D was precisely because it HAS a GC with full 
support. I wouldn't even have considered it if it hadn't.


You are probably not in a minority among those that use D for 
productive purposes, basically doing batch-like programming (or 
with similar requirements).


Nothing wrong with making that a focus, but then that would be a 
direction. There are other (growing) alternatives in that 
direction too...




Re: Why many programmers don't like GC?

2021-01-18 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Monday, 18 January 2021 at 12:17:24 UTC, aberba wrote:
If you read the Origin of D book, you would see that the GC was 
a desire thing when D was designed probably due to how useful 
it is for ... as said, 90% or so of software development. So at 
this point, fighting the GC isn't (in my opinion) the right 
strategy.


Not fighting the GC, but the whole argument about improving it, 
or mix or match, does not work for most developers looking for a 
new language. So either there has to be something else or the 
language semantics will have to be adjusted to get a better GC. 
That is the crux, the GC cannot be significantly improved without 
some minor adjustment to the language (with some breaking 
changes).


To get there the majority have to be in favour of it. If 50% of 
the D community pulls strongly in the opposite direction, then 
the GC cannot improve in a meaningful way.


Yes, it is natural that the current D population don't mind the 
current GC. Otherwise they would be gone... but then you have to 
factor in all the people that go through the revolving door and 
does not stay. If they stayed the eco system would be better. So 
the fact that they don't... is effecting everyone in a negative 
way (also those that har happy with the runtime).



I should also say that I notice your point about improving GC 
in D and making it more optional as much as possible for things 
that still rely on GC...ARC, etc. 


ARC is a pretty big change, so it will depend on library authors 
supporting it. It also requires a new intermediate 
representation. So I don't think it will happen. Thread local GC 
seems most reasonable. As CPUs get more and more threads it 
becomes more and more unacceptable to lock all threads during 
collection.



The OP was about why programmers don't "like" GC.


Programmers like GC, just not for system level programming. C++ 
has had the Boehm GC since the mid 90s. Only a tiny percentage 
use it. Forget about game engines, many games have game contents 
written in Lua and other scripting languages and can live with 
incremental GC with very little impact on interaction (you could 
use Javascript too). The game engine itself is usually not 
relying on GC, just the game content part.



I've been here long enough to see the GC being one of the most 
re-occurring issues for discussion (probably due to new users 
coming in).


Yes, they come in, but do they stay? If they don't stay, then our 
eco system suffers from it.


D would be in a better position by tracking why people leave and 
then fix those concerns (if they are related to the 
language/runtime).


There's been official posts about how D's style of GC isn't 
like that of fully managed languages, how to write nogc code in 
D, how to minimize GC, among others.


Yes, but people who are well versed in system level programming 
know how to to this already, they just want more hassle than they 
get in other languages. And those are also the same people that 
would write solid libraries/improve on the compiler. So not being 
able to retain those developers is a big loss.



Now if none of these work for you (for some special reason), 
then the long-term strategy might be an alternative runtime and 
or std. Which isn't a good answer that thought was worth 
it...so I didn't include that.


Actually that is a good answer, if it comes with the appropriate 
language changes, like tagged unions and banning conflicting 
pointers in unions.


What works for me, is not the issue, but what IS the direction?? 
Where are we going? That is the real issue.


I am perfectly ok with C++20 for low level programming. I don't 
need D for that. It is totally OK if the D community decides to 
make it more high level and easier to deal with for newbies who 
come from Python.



If none of these work, then I (as in my personal opinion), 
don't know what else is available.


I am ok with any one of these alternatives:

Alternative 1: Adjust the language semantics so that the GC can 
be improved and accept some breaking changes.


Alternative 2: Switch focus from being a system level language to 
becoming more of a high level language.


Alternative 3: Implement ARC.

The other alternatives don't really work. Doing what Rust does is 
now 2 years late, it would take 5 years to get there. Doing what 
C++ does, does not help. Why would I use D instead of C++ then?


Just pick a direction, because right now, the direction is not 
very clear and then progress becomes impossible. No direction, 
means no progress...


Re: Why many programmers don't like GC?

2021-01-18 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Monday, 18 January 2021 at 11:43:20 UTC, aberba wrote:
Nevertheless, GC in D isn't going anywhere. And if the approach 
for writing nogc code in D doesn't cut it, then I'm not what 
else will.


As long as that attitude prevails, D will be going nowhere as 
well.




Re: Why many programmers don't like GC?

2021-01-17 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
On Saturday, 16 January 2021 at 00:20:16 UTC, Guillaume Piolat 
wrote:
It's certainly true that in team dynamics, without any reward, 
efficiency can be victim to a tragedy of commons.


Well, any software invariant is harder to hold if the 
shareholders don't care.

(be it "being fast", or "being correct", or other invariants).


Yes, although for Open Source I think the "mental model" you 
talked about is more of an issue. How many people working on DMD 
has good mental model of it? It is a bit easier for programs like 
Gimp that can be "plugin" style. I guess Phobos is also "plugin" 
style, so it is easier to improve Phobos than DMD, because of the 
"mental model" issue.


Maybe Open Source projects should be designed more for simple 
mental models (with "plugins") than for high throughput too. 
Maybe we can have languages that are better for Open Source by 
making it easier to make extensions of the software with only 
local impacts.


Maybe it would be better for DMD to move away from "thread local" 
thinking and instead have a thread pool and stackless actors. 
Then tie local non-incremental garbage collection to actors. 
Useful for application development and servers, but not so useful 
for audio-plugins. So, you would probably not want it...






Re: Why many programmers don't like GC?

2021-01-15 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Friday, 15 January 2021 at 22:13:01 UTC, Max Haughton wrote:
I think the way forward is some robust move semantics and 
analysis like Rust. I suppose ideally we would have some kind 
of hidden ARC behind the scenes but I don't know how that would 
play with structs.


If they are heap allocated then you just put the reference count 
at a negative offset (common strategy).


You need pointer types for it, but that is not a big issue if the 
strategy is to support both the old GC and ARC.  You basically 
just need to get library authors that support ARC to mark their 
library code in some way.





Re: Why many programmers don't like GC?

2021-01-15 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Friday, 15 January 2021 at 21:18:55 UTC, aberba wrote:

TL;DR:

In summation, the garbage collection system is a robust part 
of Unreal Engine that affords C++ programmers a lot of safety 
from memory leaks, as well as convenience. With this 
high-level discussion, I was aiming to introduce the system at 
a conceptual level, and I hope I have achieved that.


What is your conceptual level? You haven't described what it 
does, and does not do. But yes, frameworks need that allow 
"scripting" in some shape or form (compiled or not) has to hide 
internal structures and intricacies and provide some convenience.


However, you write your own from scratch you can often times 
build the marking into an existing pass, so you get it for free. 
Not uncommon for people who write code that modify graphs.


There is a big difference between writing a dedicated collector 
for a dedicated graph, and a general ownership mechanism for the 
whole program.






Re: Why many programmers don't like GC?

2021-01-15 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Friday, 15 January 2021 at 21:15:29 UTC, aberba wrote:
Isn't it more theoretical/imaginary/hypothetical than something 
really measured from a real-world use case? Almost all large 
software use cases I've seen used mix and match.


No?! Chrome has a garbage collector because JavaScript acquire 
resources in a somewhat chaotic manner, but they have fine tuned 
it and only call it when the call stack is short.


High quality game engines have similarly fine tuned collection, 
and not really a big sweeping conservative scan that lock down 
threads.



(BTW ARC is also another form of GC)


By GC in this thread we speak of tracing GC. Generally, in 
informal contexts GC always means tracing GC, even among 
academics.


Legends have it that almost every major software project in ANY 
system language ends up writing custom allocators and 
containers.


Containers certainly, allocators, sometimes. But that is not 
necessarily related to handling ownership. You can write your own 
allocator and still rely on a standard ownership mechanism.







Re: Why many programmers don't like GC?

2021-01-15 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
On Friday, 15 January 2021 at 19:37:12 UTC, Guillaume Piolat 
wrote:

A small GC heap is sufficient.
There is this blog post where there was a quantitative measure 
of the sub-1ms D GC heap size.


That's ok for a small game, but not for applications that grow 
over time or projects where the requirement spec is written (and 
continually added to) by customers. But for enthusiast projects, 
that can work.


Many open source projects (and also some commercial ones) work ok 
for small datasets, but tank when you increase the dataset. So 
"match and mix" basically means use it for prototyping, but 
do-not-rely-on-it-if-you-can-avoid-it.


Switching to ARC looks more attractive, scales better and the 
overhead is more evenly distributed. But it probably won't happen.




Re: Why many programmers don't like GC?

2021-01-15 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
On Friday, 15 January 2021 at 18:43:44 UTC, Guillaume Piolat 
wrote:
Calling collect() isn't very good, it's way better to ensure 
the GC heap is relatively small, hence easy to traverse.
You can use -gc=profile for this (noting that things that can't 
contain pointer, such as ubyte[], scan way faster than void[])


Ok, so what you basically say is that the number of pointers to 
trace was small, and perhaps also the render thread was not under 
GC control?


I think it is better with something simpler like saying one GC 
per thread


But then ownership doesn't cross threads, so it can be tricky 
to keep object alive when they cross threads. I think that was 
a problem in Nim.


What I have proposed before is to pin down objects with a ref 
count when you temporarily hand them to other threads. Then the 
other thread will handle it with a smart_pointer which release 
the "borrow ref count" on return.


But yes, you "need" some way for other threads to borrow thread 
local memory, in order to implement async services etc.  Then 
again, I think people who write such service frameworks will be 
more advanced programmers than those that use them. So I wouldn't 
say it is a big downside.


But sometimes that ownership is just not interesting. If you 
are writing a hello world program, no one cares who "hello 
world" string belongs to. So the GC is that global owner.


I get your viewpoint, but simple types like strings can be 
handled equally well with RC... If we take the view, that you 
also stressed, that it is desirable to keep the tracable pointer 
count down, then maybe making only class object GC is the better 
approach.


Re: Why many programmers don't like GC?

2021-01-15 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
On Friday, 15 January 2021 at 16:26:59 UTC, Guillaume Piolat 
wrote:
Until someone can describe a strategy that works for a full 
application, e.g. an animation-editor or something like that, 
it is really difficult to understand what is meant by it.


Personal examples:
 - The game Vibrant uses GC for some long-lived objects.
   Memory pools for most game entities.
   Audio thread has disabled GC.


But when do you call collect? Do you not create more and more 
long-lived objects?


- Dplug plugins before runtime removal used GC in the UI, but 
no GC in whatever was called repeatedly, leading to no GC pause 
in practice. In case an error was made, it would be a GC pause, 
but not a leak.


How do you structure this? Limit GC to one main thread? But an 
audio plugin GUI is not used frequently, so... hickups are less 
noticable. For a 3D or animation editor hickups would be very 
annoying.


The pain point with the mixed approach is adding GC roots when 
needed. You need a mental model of traceability.


Yes. I tend to regret "clever" solutions when getting back to the 
code months later because the mental model is no longer easily 
available.


I think it is better with something simpler like saying one GC 
per thread, or ARC across the board unless you use non-arc 
pointers, or that only class objects are GC. Basically something 
that creates a simple mental model.


It really is quite easy to do: build you app normally, 
evetually optimize later by using manual memory management.


I understand what you are saying, but it isn't all that much more 
work to use explicit ownership if all the libraries have support 
for it.


It is a lot more work to add manual memory management if the 
available libraries don't help you out.





Re: Why many programmers don't like GC?

2021-01-15 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Friday, 15 January 2021 at 16:21:43 UTC, jmh530 wrote:
On Friday, 15 January 2021 at 15:36:37 UTC, Ola Fosheim Grøstad 
wrote:
The library smart pointers would make it difficult to interact 
with existing D GC code though.


Yes. So it would be better to do it automatically in the compiler 
for designated GC objects.


ARC is also a good alternative.

Probably less work to get a high quality ARC implementation, than 
a high quality GC implementation.




Re: Why many programmers don't like GC?

2021-01-15 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
On Friday, 15 January 2021 at 15:50:59 UTC, Guillaume Piolat 
wrote:

On Friday, 15 January 2021 at 11:11:14 UTC, Mike Parker wrote:


That's the whole point of being able to mix and match. Anyone 
avoiding the GC completely is missing it (unless they really, 
really, must be GC-less).


+1
mix and match is a different style versus only having a GC, or 
only having lifetimes for everything. And it's quite awesome as 
a style, since half of things don't need a well-identified 
owner.



What do you mean by "mix and match"? If it means shutting down 
the GC after initialization then it can easily backfire for more 
complicated software that accidentally calls code that relies on 
the GC.


Until someone can describe a strategy that works for a full 
application, e.g. an animation-editor or something like that, it 
is really difficult to understand what is meant by it.





Re: Why many programmers don't like GC?

2021-01-15 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Friday, 15 January 2021 at 15:48:07 UTC, welkam wrote:
On Friday, 15 January 2021 at 14:35:55 UTC, Ola Fosheim Grøstad 
wrote:

improved with precise collection

Precise GC is slower than default GC.


D does not have a fully precise GC. The "precise" collector still 
scans things conservatively when it cannot be certain.


If you combine fully precise collection it with static analysis, 
then you can reduce the number of paths you follow, but it is a 
lot of work to implement. So it would take a very motivated 
individual.


-lowmem flag replaces all* allocations with GC allocations so 
you can benchmark that


Interesting idea. There are compilers that use GC written in 
other languages. It is a nice baseline test, especially since 
there are not many large commonly known programs for D to do 
realistic benchmarks with.


A write barrier is a peace of code that is inserted before a 
write to an [object].


Not a write to the object, but a modified pointer. The write 
barrier is invoked when you switch a pointer from one object to 
another one. Then you mark the object, so you need 2 free bits in 
each object to use for marking.


But my uncertainty was related to how to optimize away barrier 
that has no impact on the final collection. It is easy to make 
mistakes when doing such optimizations. The goal should be to 
invoke as few barriers as possible by static analysis.


Reference counting needs mutation. How do you define immutable 
RC slice that needs to mutate its reference count? Thats a 
unsolved problem in D.


D needs more fine grained immutable, for sure.



Re: Why many programmers don't like GC?

2021-01-15 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Friday, 15 January 2021 at 15:20:05 UTC, jmh530 wrote:
Hypothetically, would it be possible for users to supply their 
own garbage collector that uses write barriers?


Yes. You could translate Google Chrome's Oilpan to D. It uses 
library smart pointers for dirty-marking. But it requires you to 
write a virtual function that points out what should be traced 
(actually does the tracing for the outgoing pointers from that 
object):






Re: Why many programmers don't like GC?

2021-01-15 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Friday, 15 January 2021 at 15:18:31 UTC, IGotD- wrote:
Bump the pointer is a very fast way to allocate memory but what 
is more interesting is what happens when you return the memory. 
What does the allocator do with chunks of free memory? Does it 
put it in a free list, does it merge chunks? I have a feeling 
that bump the pointer is not the complete algorithm that D uses 
because of that was the only one, D would waste a lot of memory.


I don't know what DMD does exactly, but I guess this is called an 
"arena" or something like that? Objective-C does something 
similar with its autorelease pool.


Basically, you have a point in the call-tree where you know that 
all work has been done and then you just reclaim everything that 
is not marked as in-long-term-use. So you don't do the mark 
phase, you put the burden of marking the object as in use on the 
object/reference and just sweep. (Or assume that everything can 
be freed, which fits well with a compiler that is working in 
discrete stages).


Side note: I incidentally wrote a little allocator cache 
yesterday that at compile time takes a list of types and then 
takes the size of those types, sorts it and builds an array of 
freelists for those specific sizes and caches objects that are 
freed if they match the desired size (then there is a threshold 
for the length of the freelist, when that is hit C free() is 
called. It should be crazy fast too, since I require the free 
call to provide the type so the correct free list is found at 
compile time, not at run time.


Re: Why many programmers don't like GC?

2021-01-15 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
On Friday, 15 January 2021 at 14:59:18 UTC, Ola Fosheim Grøstad 
wrote:

On Friday, 15 January 2021 at 14:50:00 UTC, welkam wrote:
avoid redundant pointers. For instance, a type for telling the 
compiler that a pointer is non-owning.


I guess "non-owning" is the wrong term. I mean pointers that are 
redundant. Not all "non-owning" pointers are redundant.




Re: Why many programmers don't like GC?

2021-01-15 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Friday, 15 January 2021 at 14:50:00 UTC, welkam wrote:
The reasoning of why we do not implement write barriers is that 
it will hurt low level programming. But I feel like if we drew 
a ven diagram of people who rely on GC and those who do a lot 
of writes trough a pointer we would get almost no overlap. In 
other words if D compiler had a switch that turned on write 
barriers and better GC I think many people would use it and 
find the trade offs acceptable.



Yes, I think this is what we need some way of making the compiler 
know which pointers has to be traced so that it can avoid 
redundant pointers. For instance, a type for telling the compiler 
that a pointer is non-owning. Then we don't have to use a write 
barrier for that non-owning pointer I think? Or maybe I am 
missing something?


Then we can also have a switch.

But I also think that we could do this:

1. Make all class objects GC allocated and use write barriers for 
those.

2. Allow non-owning annotations for class object pointers.
3. Make slices and dynamic arrays RC.
4. Let structs be held by unique_ptr style (Rust/C++ default).

Then we need a way to improve precise tracing:
1. make use of LLVM precise stack/register information
2. introduce tagged unions and only allow redundant pointers in 
untagged unions

3. Each compile phase emits information for GC.
4. Before linking the compiler generates code to narrowly trace 
the correct pointers.


Then we don't have to deal with real time type information lookup 
and don't have to do expensive lookup to figure out if a pointer 
points to GC memory or not. The compiler can then just assume 
that the generated collection code is exact.




Re: Why many programmers don't like GC?

2021-01-15 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Friday, 15 January 2021 at 14:24:40 UTC, welkam wrote:
You can use GC with D compiler by passing -lowmem flag. I didnt 
measure but I heard it can increase compilation time by 3x.


Thanks for the info. 3x is a lot though, maybe it could be 
improved with precise collection, but I assume that would require 
a rewrite.


Making it use automatic garbage collection (of some form) would 
be an interesting benchmark.




Re: Why many programmers don't like GC?

2021-01-15 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Friday, 15 January 2021 at 11:11:14 UTC, Mike Parker wrote:
That's the whole point of being able to mix and match. Anyone 
avoiding the GC completely is missing it (unless they really, 
really, must be GC-less).


Has DMD switched to using the GC as the default?


Re: Why many programmers don't like GC?

2021-01-15 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Friday, 15 January 2021 at 07:35:00 UTC, H. S. Teoh wrote:
To be fair, the GC *has* improved over the years.  Just not as 
quickly as people would like, but it *has* improved.


It cannot improve enough as a global collector without write 
barriers. No language has been able to do this. Therefore, D 
cannot do it.


Precise collection only helps when you have few pointers to trace.


improvement. But why would I?  It takes 5x less effort to write 
GC code, and requires only a couple more days of effort to fix


That's like saying it takes 5x more time to write code in Swift 
than D. That is not at all reasonable.


Tracing GC is primarily useful when you have many small 
long-lived objects with unclear ownership and cyclic references 
that are difficult to break with weak pointers.


In those cases it is invaluable, but most well-designed programs 
have more tree-like structures and clear ownership.



after that to debug obscure pointer bugs.  Life is too short to 
be squandered chasing down the 1000th double-free and the 
20,000th dangling pointer in my life.


That has nothing to do with a tracing GC... Cyclic references is 
the only significant problem a tracing GC addresses compared to 
other solutions.



A lot of naysayers keep repeating GC performance issues as if 
it's a black-and-white, all-or-nothing question.  It's not.  
You *can* write high-performance programs even with D's 
supposedly lousy GC -- just profile the darned thing, and


There are primarily two main problems, and they are not 
throughput, they are:


1. LATENCY: stopping the world will never be acceptable in 
interactive applications of some size, it is only acceptable in 
batch programs. In fact, even incremental collectors can cause a 
sluggish experience!


2. MEMORY CONSUMPTION: doing fewer collection cycles will 
increase the memory footprint. Ideally the collector would run 
all the time. In the cloud you pay for memory, so you want to 
keep memory consumption to a fixed level that you never exceed.



System level programming is primarily valuable for interactive 
applications, OS level programming, or embedded. So, no, it is 
not snobbish to not want a sluggish GC. Most other tasks are 
better done in high level languages.





Re: Why many programmers don't like GC?

2021-01-14 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Thursday, 14 January 2021 at 18:10:43 UTC, mw wrote:

Python's `del` isn't guaranteed to free the memory, that's what


Fair point, but I was thinking of the C interop interface. You 
can create your own wrapper (e.g. numpy) and do manual memory 
management, but it isn't something people want to do! It is 
mostly pointless to do that within Python because of the existing 
overhead.  That applies to most high level languages; you can, 
but it is pointless. You only do it for interop...


One can follow the same kind of reasoning for D. It makes no 
sense for people who want to stay high level and do batch 
programming. Which is why this disconnect exists in the 
community... I think.




Re: Why many programmers don't like GC?

2021-01-14 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Thursday, 14 January 2021 at 13:05:31 UTC, sighoya wrote:
But this is already the case for C++ and Rust. Remembering the 
days back developing in C++ there were a huge amount of memory 
deallocation side effects because opencv's memory management 
differs from qt's memory management.


The problem in C++ is that older frameworks have their own ways 
of doing things for performance reasons or because the C++ 
standard they started with didn't provide what they needed...


And... most C++ frameworks that are big are old... If you avoid 
big frameworks then it gets better.


Personally, I find it better to prefer encapsulating manual 
memory management and not to leak them outside.


Yes. Most programmers don't need system level programming. So if 
D defines itself to not be a system level programming language 
then there would be room to improve a lot, but then it should 
move towards more high level features and prevent the usage of 
some low level features like untagged non-discriminating unions 
of pointers. Rust is more high level than D... I think.




Re: Why many programmers don't like GC?

2021-01-14 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
On Thursday, 14 January 2021 at 13:16:16 UTC, Ola Fosheim Grøstad 
wrote:
1. Use "shared" to prevent GC allocated memory from entering 
other threads and switch to thread local GC. Then use ARC for 
shared.


2. Redefine language semantics/type system for a different GC 
model. This will break existing code.


3. Keep the existing GC for existing code and introduce ARC 
across the board for new code. Add a versioning statement that 
people can add to their libraries to tell the compiler which 
models they support.






Re: Why many programmers don't like GC?

2021-01-14 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Thursday, 14 January 2021 at 13:10:14 UTC, sighoya wrote:
On Thursday, 14 January 2021 at 13:08:06 UTC, Ola Fosheim 
Grøstad wrote:


Because Java has a well defined virtual machine with lots of 
restrictions.


So you're insisting this isn't possible in D?


It isn't possible in a meaningful way.

In system level programming languages you have to manually uphold 
the invariants needed to not break the GC collection algorithm.


So if you change to a significantly different collection model, 
the needed invariants will change.


The possible alternatives are:

1. Use "shared" to prevent GC allocated memory from entering 
other threads and switch to thread local GC. Then use ARC for 
shared.


2. Redefine language semantics/type system for a different GC 
model. This will break existing code.







Re: Why many programmers don't like GC?

2021-01-14 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Thursday, 14 January 2021 at 13:01:04 UTC, sighoya wrote:

Why not offering more than one just as it is the case in Java?
The advantage hereby is to adapt the GC algorithm after the 
program was compiled, so you can reuse the same program with 
different GC algorithms.


Because Java has a well defined virtual machine with lots of 
restrictions.




Re: Why many programmers don't like GC?

2021-01-14 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Thursday, 14 January 2021 at 10:28:13 UTC, Basile B. wrote:

Semi serious answer:

In the domain of hoby-ism and small companies programmers that 
work with statically typed languages all believe that they are 
super hero in the domain of memory managment. When they see 
"GC" they think that they are considered as 2nd grade student ^^


It's basically snobbism.


I know your response is *tongue in cheek*, but I actually find it 
easier to use c++11 style memory management across the board than 
mixing two models.


C style memory management, on the other hand, is pretty horrible 
and you'll end up spend much of your time debugging 
"unexplainable" crashes. I don't experience that much in C++ when 
staying within their standard regime.


When you want more performance than standard C++ memory 
management, things can go wrong e.g. manual emplace strategies 
and forgetting to call destructors etc, but that is the same in 
D. And frankly, you seldom need that, maybe 2-3 critical places 
in your program (e.g. graphics/audio).




Re: Why many programmers don't like GC?

2021-01-14 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
On Thursday, 14 January 2021 at 10:05:51 UTC, Guillaume Piolat 
wrote:

On Wednesday, 13 January 2021 at 18:58:56 UTC, Marcone wrote:
I've always heard programmers complain about Garbage Collector 
GC. But I never understood why they complain. What's bad about 
GC?


Languages where the GC usage is unavoidable (Javascript and 
Java) have created a lot of situations where there is a GC 
pause in realtime program and the cause is this dynamically 
allocated memory. So a lot of people make their opinion of GC 
while using setup where you couldn't really avoid it.


Indeed, but I don't think we should underestimate the perceived 
value of having a minimal runtime. Like, if D had a better GC 
solution that involved an even heavier runtime, it would still be 
a big issue for people interested in low level system programming.


Transparency is an issue. System level programming means you want 
to have a clear picture of what is going on in the system at all 
levels, all the way down to the hardware. If you cannot 
understand how the runtime works you also cannot fix issues... so 
a simple runtime is more valuable than a feature rich complex 
runtime.


That is kinda what defines system level programming: you know 
exactly what every subsystem is doing so that you can anticipate 
performance/resource issues. And that is the opposite of high 
level programming where you make no assumptions about the 
underlying machinery and only care about the abstract 
descriptions of language semantics.







Re: Why many programmers don't like GC?

2021-01-14 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Thursday, 14 January 2021 at 00:37:29 UTC, mw wrote:

ok, what I really mean is:

... in other "(more popular) languages (than D, and directly 
supported by the language & std library only)" ...


Well, even Python supports both, if you want to, so... I suppose 
you mean system level programming languages? The reality is that 
GC for a system level programming language is not popular to 
begin with. In that domain it is fairly common to not use the 
standard library and use custom runtimes as we can see for C and 
C++.


Anyway, what makes the D GC weak is exactly that there is not 
much support for it in the D language or the compilers, only in 
the runtime and the bare minimum of RTTI. LLVM support more 
advanced GC features than D provides.


So, the D GC doesn't do much more for programmers than Boehm. And 
Boehm is not popular either...


Oilpan, that Chrome uses has more advanced features than the D 
GC, and does what most system level programmers want: limits it 
to designated GC types and supports incremental collection. The 
downside is that each Oilpan GC type also has to specify which 
pointers to trace, but then again, not being able to do that in D 
is a disadvantage...


For systems programming, I think D would be better off 
appropriating the approach taken by Oilpan and mix it with 
reference counting, but make it a language/compiler feature. That 
is at least a proven approach for one big interactive 
application. Basically make "D class" objects GC and everything 
else RC or manual.






Re: Why many programmers don't like GC?

2021-01-13 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 21:56:58 UTC, mw wrote:
I think this flexibility to mix GC & manual memory management 
is very unique in D. Actually I'm not sure if it can be done in 
other languages at all.


It sure can. Most AOT languages that provide GC also provide 
C-interfaces and manual memory management. C++ also had the 
Boehm-collector since the 90s. Chrome uses Oilpan, a 
library-style GC with write barriers and incremental collection.









Re: Why many programmers don't like GC?

2021-01-13 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 18:58:56 UTC, Marcone wrote:
I've always heard programmers complain about Garbage Collector 
GC. But I never understood why they complain. What's bad about 
GC?


tsbockman gave a good answer.

In short:

- You need to design the language for GC for it to be a 
satisfying solution for interactive applications. For D and C++ 
it is bolted on... which is not great.


- You will use roughly twice as much memory with GC (you get more 
garbage).


- You will get more uneven performance with GC (humans are 
smarter).




Re: I want to create my own Tuple type

2021-01-12 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Tuesday, 12 January 2021 at 21:38:59 UTC, sighoya wrote:

What about this?
No magic, but I don't know the performance impact.

```
import std.meta;
import std.conv;

template same(Types...)
{
static if (Types.length >= 2)
{
static if (is(Types[0] == Types[$ - 1]))
{
const same = same!(Types[1 .. $]);
}
else
{
enum bool same = false;
}
}
else
{
enum bool same = true;
}
}


I also like the recursive version better. I borrowed the core 
concept from Phobos. I assume they don't use recursion because 
they are afraid of running out of stack space? Or maybe it is 
because of performance?




struct Tuple(Types...)
{

static if (same!Types)
{
public Types[0][Types.length] elements;


Yes, this is what I also felt was the right approach. But then I 
realized that AliasSeq (which is what you get if you use "Types 
expand") is hardwired in the compiler in a hackish way so that 
you get various features from it, like implicit splatting 
(expanding the sequence into arguments)?  That kinda makes it 
difficult to get the right semantics as I know of no way to do it 
without AliasSeq, but maybe there is some way, perhaps one can 
convert it into an AliasSeq somehow.


I kinda don't like this kind of compiler-magic for one specific 
type as it limits what you can do, but I guess it was done for 
easy-of-implementation.



static foreach (int i, T; Types)
{
mixin("public " ~ T.stringof ~ " " ~ "elem" ~ 
i.stringof ~ ";");

}


Yep, I had this version at some point :-)

I think the way you approached it is the intuitive way, but the 
problem is really that AliasSeq get special treatment by the 
compiler so it is currently difficult to work around it?


One should probably look closer at the language semantics and try 
to come up with a more generic mechanism as that would make for 
more powerful meta programming.






Re: I want to create my own Tuple type

2021-01-12 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
Ok, so I now have this, but I think maybe the switch could be 
turned into a static array by an reinterpret cast of 
"[0]"? I would assume the layout would typically be 
"expand_field_0, expand_field_1 etc...



template Tuple(Types...){
template same(){
static foreach (i, dummy; Types) {
static if (i + 1 < Types.length && !is(typeof(same) 
== bool)

   && !is(Types[i] == Types[i + 1])) {
enum bool same = false;
}
}
static if (!is(typeof(same) == bool)) {
enum bool same = true;
}
}

struct Tuple {
Types expand;
alias expand this;

static if (same!()) {
auto opIndex(size_t i) {
switch (i) {
static foreach (j; 0 .. Types.length) {
case j: return this.expand[j];
}
default: assert(0);
}
}
}
}
}




Re: I want to create my own Tuple type

2021-01-11 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Monday, 11 January 2021 at 20:52:25 UTC, Paul Backus wrote:
All of what you're saying applies equally well to any struct 
type as it does to tuples.


Sure.

It sounds like what you really want is for D *in general* to 
have head-const, for all types. So there's no reason to force 
it on tuples in particular. Just write your DIP for 'readonly', 
and if it's accepted, you can write `readonly(Tuple)` and get 
the result you want for free.


More like head-immutable, but yes.



Re: I want to create my own Tuple type

2021-01-11 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Monday, 11 January 2021 at 19:25:06 UTC, Paul Backus wrote:
I agree that immutability has benefits, but I don't see why 
tuples should be singled out for special treatment in this 
regard.


Oh, and another reason is that scalars can usually be passed by 
value with impunity, but you might want to pass tuples by 
reference as it could save you some copying in a significant way. 
And pass by reference would make the tuple vulnerable to 
mutation... (since we don't have head-const).





Re: I want to create my own Tuple type

2021-01-11 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Monday, 11 January 2021 at 19:25:06 UTC, Paul Backus wrote:
On Monday, 11 January 2021 at 18:02:19 UTC, Ola Fosheim Grøstad 
wrote:

On Monday, 11 January 2021 at 17:48:13 UTC, Paul Backus wrote:
Why? I'd say that an `immutable(Tuple)` should be immutable, 
and a `Tuple` should be mutable, as is the case with 
literally every other type in D.


Tuples are usually immutable, it brings more correctness.


I agree that immutability has benefits, but I don't see why 
tuples should be singled out for special treatment in this 
regard. Why is immutability more important for tuples than for 
any other kind of data?


Well, maybe not more important, but at least consistent with 
mathematics. :-)


I guess my real reason is that I am not ready to reimplement the 
type system and add one-level "readonly" semantics to the 
language at this point, so just preventing writable reference 
from leaking out seems one temporary approach that could work.


What I don't want is to have a tuple accidentally modified, so if 
one wants to modify the tuple then one should bind it to 
variables through destructuring? I guess that is a good reason? 
The caller of a function can decide to set up the return value 
from a function for mutation by destructuring the tuple.


I guess that would be the "idiomatic" pattern...





Re: I want to create my own Tuple type

2021-01-11 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Monday, 11 January 2021 at 17:48:13 UTC, Paul Backus wrote:
Why? I'd say that an `immutable(Tuple)` should be immutable, 
and a `Tuple` should be mutable, as is the case with literally 
every other type in D.


Tuples are usually immutable, it brings more correctness.



Re: properly passing strings to functions? (C++ vs D)

2021-01-11 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Monday, 11 January 2021 at 16:40:53 UTC, Ali Çehreli wrote:
Yes. Earlier C++ string implementations used reference 
counting, which caused multi-threading complications; so, many 
implementations switched to copying.


Ah, I guess I've never used std::string for anything that 
requires speed. Turns out that cpp.sh is outdated.




Re: I want to create my own Tuple type

2021-01-11 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
On Monday, 11 January 2021 at 14:53:08 UTC, Ola Fosheim Grøstad 
wrote:
On Monday, 11 January 2021 at 14:51:29 UTC, Ola Fosheim Grøstad 
wrote:

On Monday, 11 January 2021 at 14:03:39 UTC, Paul Backus wrote:

alias expand this;


Hm... this does not allow me protect the fields from being 
changed. I also cannot use const since it is transitive and 
would make it impossible to return two references to mutable 
objects?


Basically, the tuple itself should be immutable, but not the 
objects being referenced. I guess I could run over the types 
and add const if they are not references?


But that would leave references mutable... so not the best 
solution. I kinda like the flexibility of __0, __1 and that it 
maps nicely to a regular struct.


I guess what I want is head-immutable (not even really head 
const).




Re: properly passing strings to functions? (C++ vs D)

2021-01-11 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
On Monday, 11 January 2021 at 15:23:23 UTC, Ola Fosheim Grøstad 
wrote:

On Monday, 11 January 2021 at 14:12:57 UTC, zack wrote:
A beginner question: How to pass strings properly to functions 
in D?
Is there any allocation going on if just use a function as 
"myPrint"? In C++ I have often seen calls where one just 
passes a reference/const reference to a string to avoid 
allocation.


C++ strings are reference counted, I think, so it is more to 
avoid a reference count increment than to avoid a collection.


I meant allocation... The following prints "1", so no allocation.

#include 
#include 

std::string a("hello world");

void f(std::string b){
std::cout << (b.data() == a.data()) << std::endl;
}

int main()
{
f(a);
}




Re: properly passing strings to functions? (C++ vs D)

2021-01-11 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Monday, 11 January 2021 at 14:12:57 UTC, zack wrote:
A beginner question: How to pass strings properly to functions 
in D?
Is there any allocation going on if just use a function as 
"myPrint"? In C++ I have often seen calls where one just passes 
a reference/const reference to a string to avoid allocation.


C++ strings are reference counted, I think, so it is more to 
avoid a reference count increment than to avoid a collection.



A D-Style String could be seen as "const(char)[]"? So as it is 
a slice it already is a kind of reference to some data 
elsewhere? Which means calling a function like "myPrint" in D 
wouldn't cause any allocation. Is this correct?


D strings are backed by GC so they are passed by reference too.




Re: I want to create my own Tuple type

2021-01-11 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Monday, 11 January 2021 at 14:03:39 UTC, Paul Backus wrote:

alias expand this;


Hm... this does not allow me protect the fields from being 
changed. I also cannot use const since it is transitive and would 
make it impossible to return two references to mutable objects?


Basically, the tuple itself should be immutable, but not the 
objects being referenced. I guess I could run over the types and 
add const if they are not references?




Re: I want to create my own Tuple type

2021-01-11 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
On Monday, 11 January 2021 at 14:51:29 UTC, Ola Fosheim Grøstad 
wrote:

On Monday, 11 January 2021 at 14:03:39 UTC, Paul Backus wrote:

alias expand this;


Hm... this does not allow me protect the fields from being 
changed. I also cannot use const since it is transitive and 
would make it impossible to return two references to mutable 
objects?


Basically, the tuple itself should be immutable, but not the 
objects being referenced. I guess I could run over the types 
and add const if they are not references?


But that would leave references mutable... so not the best 
solution. I kinda like the flexibility of __0, __1 and that it 
maps nicely to a regular struct.


Re: I want to create my own Tuple type

2021-01-11 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Monday, 11 January 2021 at 14:03:39 UTC, Paul Backus wrote:
On Monday, 11 January 2021 at 09:42:39 UTC, Ola Fosheim Grøstad 
wrote:

On Monday, 11 January 2021 at 05:59:03 UTC, Paul Backus wrote:
You can just fall back to `alias expand this` like Phobos's 
Tuple does in this case. No compiler modification needed.


I though maybe it would be nice in general to be able to 
create static indexed type by having a special field name 
pattern, but I will have a another look at staticMap (I don't 
really want the full staticMap into object.d though).


I have no idea why you're bringing up staticMap here. The 
simplest way to create a tuple's fields is to use type sequence 
instantiation [1], like Phobos does:


Ok, thanks. I guess typecons only use staticMap because it allows 
for named fields.




Re: I want to create my own Tuple type

2021-01-11 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
On Monday, 11 January 2021 at 09:42:39 UTC, Ola Fosheim Grøstad 
wrote:
I though maybe it would be nice in general to be able to create 
static indexed type by having a special field name pattern, but 
I will have a another look at staticMap (I don't really want 
the full staticMap into object.d though).


This is the core of staticMap, I find it problematic to do this 
kind of string mixin in object.d:


private enum staticMapExpandFactor = 150;
private string generateCases()
{
string[staticMapExpandFactor] chunks;
chunks[0] = q{};
static foreach (enum i; 0 .. staticMapExpandFactor - 1)
chunks[i + 1] = chunks[i] ~ `F!(Args[` ~ i.stringof ~ 
`]),`;

string ret = `AliasSeq!(`;
foreach (chunk; chunks)
ret ~= `q{alias staticMap = AliasSeq!(` ~ chunk ~ `);},`;
return ret ~ `)`;
}
private alias staticMapBasicCases = 
AliasSeq!(mixin(generateCases()));







Re: I want to create my own Tuple type

2021-01-11 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Monday, 11 January 2021 at 05:59:03 UTC, Paul Backus wrote:

static if (allSameType) {
auto opIndex(size_t i) {
switch (i) {
static foreach (j; 0 .. Types.length) {
case j: return this.expand[j];
}
default: assert(0); // or throw RangeError
}
}
}

Any decent compiler will turn this into `return this.expand[i]`.


Maybe, I would then have to test for release mode and replace 
default: faulting with "unreachable"...


I guess I won't know how this works out without testing, but it 
would in general be nice to be sure that a reinterpret cast to a 
static array would work.


If the types are different I want static indexing, so the plan 
is to resolve failed lookup as __0 etc by modifying the 
compiler.


You can just fall back to `alias expand this` like Phobos's 
Tuple does in this case. No compiler modification needed.


I though maybe it would be nice in general to be able to create 
static indexed type by having a special field name pattern, but I 
will have a another look at staticMap (I don't really want the 
full staticMap into object.d though).


I am a bit worried about compile time implications as I use 
tuples more and more in my own code, and expect that is a common 
trend...


Maybe one could special case arity 0,1,2,3,4,5,6,7,8 and use a 
more generic template for 9 and up.




I want to create my own Tuple type

2021-01-10 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
I want to create my own Tuple type, and I don't like the messy 
implementation of the one in D's standard lib, or the one in 
Clang++'s standard lib. The concept is very simple so it is 
disheartening if it cannot be done in a simple way that does not 
impact compile times... :-/


The requirements are:

1. It should not lead to slower compile times than fixed arity 
templates (if so, then I would just list all sizes from 0..64 
instead).


2. If all types are similar then it should be implemented as a 
static array with indexing. If not, then all fields should have 
the names __0, __1 etc.



Something along the lines of, but not with fixed arity:


struct Tuple(){}

struct Tuple(T0){
T0[1] __v;
const ref opIndex(size_t i){ return __v[i]; }
}

struct Tuple(T0,T1){
static if (is(T0==T1)) {
T0[2] __v;
this(T0 a, T1 b){__v[0]=a; __v[1]=b; }
const ref opIndex(size_t i){ return __v[i]; }
} else {
T0 __0;
T1 __1;
}
}

auto _tuple(Ts...)(Ts args){
return __Tuple!Ts(args);
}




Re: DConf talk : Exceptions will disappear in the future?

2021-01-06 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Wednesday, 6 January 2021 at 21:27:59 UTC, H. S. Teoh wrote:
It must be unique because different functions may return 
different sets of error codes. If these sets overlap, then once 
the error propagates up the call stack it becomes ambiguous 
which error it is.


I don't think this is the case. If you analyse the full program 
then you know the functions that interact. All you need to do is 
dataflow analysis.


I also don't think there should be a specific error-code, I think 
that should be left implementation defined. The program should 
just specify a set of errors. Then it is up to the compiler if 
that for a given call can be represented using some free bits in 
another return value as a nullpointer or whatever.


If speed is what is sought, well, then design for it. :-)



Re: DConf talk : Exceptions will disappear in the future?

2021-01-05 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Tuesday, 5 January 2021 at 21:46:46 UTC, H. S. Teoh wrote:
implemented, rather than the concept of exceptions itself.  If 
we implement Sutter's proposal, or something similar suitably 
adapted to D, it would eliminate the runtime overhead, solve 
the @nogc exceptions issue, and still support traditional 
polymorphic exception objects that some people still want.


I am not against it per se, but one caveat is that it would not 
be compatible with C++.


Also, I think this is better determined using whole program 
optimization, the chosen integer bit pattern used for propagating 
errors has performance implications. The most freguently 
thrown/tested value should be the one tested most on performance 
critical paths.


Well, I guess you could manually assign integer values where 
there is important and autogenerate the others.


Re: DConf talk : Exceptions will disappear in the future?

2021-01-05 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
On Tuesday, 5 January 2021 at 22:01:08 UTC, Ola Fosheim Grøstad 
wrote:
Also, I think this is better determined using whole program 
optimization, the chosen integer bit pattern used for 
propagating errors has performance implications. The most 
freguently thrown/tested value should be the one tested most on 
performance critical paths.


I messed that sentence up in editing :/...

The most frequently thrown/tested values on performance critical 
paths should be represented with a bitpattern that is most easily 
tested. (you can test for more than one value using a single 
bitand, etc).




Re: DConf talk : Exceptions will disappear in the future?

2021-01-05 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Tuesday, 5 January 2021 at 18:23:25 UTC, sighoya wrote:
No error handling model was the HIT and will never be, 
therefore I would recommend to leave things as they are and to 
develop alternatives and not to replace existing ones.


Or implement C++ exceptions, so that D can catch C++ exceptions 
transparently (ldc catch clang++ exceptions and gdc catch g++ 
exceptions).






Re: C++ or D?

2021-01-01 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Friday, 1 January 2021 at 18:00:57 UTC, SealabJaster wrote:
Meanwhile I believe C++ (keep in mind I very rarely touch or 
look at C++) already has a standard allocator interface that 
parts of the STL (and I assume libraries, when/if they care) 
are able to use? I'm unaware of the issues it might have in 
C++, but that's mostly because of my lack of use and knowledge 
of the language. It has standard pointer types, etc.


So, C++ had the same issues as D prior to C++11, that you had 
many many different options, but none of them were standard... 
Which was ok if you used one big framework, but if you wanted to 
mix libraries... yuck. Since C++11 things are looking better 
although it obviously takes time for frameworks/libraries to 
catch up.


In C++ everything is up to the library/programmer so there is 
basically no way for the compiler to be particularly clever with 
heap allocations, although it can be clever with values (e.g. 
stack allocations).  So, that is an area where D could be bold 
make the compiler smart, and do better than C++, but that takes 
some courage.


C++ smart pointers do allow for custom allocators, but then the 
owning pointers will have an extra field for referencing it, 
which is used for deallocation. I suspect most people don't use 
it, but it might be important for creating nice C++ wrappers for 
C libraries?


I wonder what problems D faces in comparison to C++ and other 
languages in this regard, since it's been in a limbo, 
fragmented state for a while now.


Mostly a lack of strategic decision making? Just map out the 
various alternatives and pick a combination that is "wholesome".


(Do you want to be a bird and fly or a fish that can swim? Being 
neither bird nor fish isn't working in the long run, I don't 
think so.)




Re: C++ or D?

2021-01-01 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Friday, 1 January 2021 at 16:23:45 UTC, SealabJaster wrote:
Slightly off but also on topic but, has there been any general 
consensus yet around standard pointer types (e.g. shared_ptr) 
and standard allocator-aware data structures, or just in 
general any discussions around non-GC memory management as part 
of Phobos/core parts of D outside of "use/write a library"?


I don't know anything about any official positions other than the 
fact that Walter dislikes having more than one pointer type and 
is working on some kind of "liveness" verification for a C-style 
free/malloc regime, which is rather rare in other languages these 
days. Not really sure how that fits with modern code bases.


Isn't there some work on move-semantics to make C++ interfacing 
better? But shared_ptr is only for C++ interop, perhaps? Or is it 
meant for D-code?


To me it looks like things are a bit up-in-the-air at the moment.

And well, having many options that are incompatible would not be 
good for library interop, so choices have to be made to avoid 
"tower of Babel".


*shrugs*



Re: C++ or D?

2021-01-01 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Friday, 1 January 2021 at 15:01:15 UTC, RSY wrote:
one big move would be to finally put the allocators out of 
std.experimental, and finally embrace this everywhere (just 
like ziglang)


I am bit torn on this, the less the compiler knows about 
allocation strategies, the less opportunity there are for the 
compiler to be smart about allocations. So, those things ought to 
be language constructs, not library constructs.


At least if D is going to stay in the lane of high level 
programming. (Zig is firmly staking ground in the manual-labour 
department, as far as I can tell.)




Re: C++ or D?

2020-12-31 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
On Thursday, 31 December 2020 at 19:27:23 UTC, Sebastiaan Koppe 
wrote:
On Thursday, 31 December 2020 at 16:03:54 UTC, Ola Fosheim 
Grøstad wrote:

What would you like to see?


For shared to mean something.
Stackless coroutines.
Compile-time lifetime management, i.e. better ways to define 
ownership.


I second that. At least some way to know whether a pointer takes 
ownership (GC/RC) or just is an auxiliary reference.




Re: C++ or D?

2020-12-31 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Thursday, 31 December 2020 at 18:13:40 UTC, Imperatorn wrote:
I was a bit unclear. I meant features as in built in language 
constructs etc, not necessarily like keywords and so on.


You mean like associative arrays and dynamic arrays? If so then I 
guess people have different taste, I think it was a mistake to 
make those builtins...


I find code harder to read when symbols (e.g. "!") have so many 
meanings in D. I am creating my own experimental unicode-syntax 
now where each symbol has only one meaning... kinda like a 
prototype for testing the idea of using the full unicode charset 
for programming. So not necessarily a D specific issue, but D is 
a nice testbed for experimenting as it has so many features.


Hmm, regarding features I'd like in C++, maybe better 
metaprogramming and fewer keywords? Haven't thought about that


I've never run into meta programming problems that I cannot deal 
with in C++ in way that works out ok in the end, but sometimes 
you have to search the web. Fortunately there are many "recipes" 
for big languages... without that... uhm. Then C++ would be a 
very difficult thing to handle :-D.


What I don't like about C++ is that things get verbose, but 
verbosity has some advantages when programs get very large 
because then you need more context to understand what is going on 
and where things are coming from.


It isn't obvious that something that is good for a medium sized 
program will be good for a very large program (e.g. "where did 
this symbol come from?"). You won't really find out until you've 
tried... but most D programs are small, so. No need to worry 
about that...






Re: C++ or D?

2020-12-31 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
On Thursday, 31 December 2020 at 14:56:37 UTC, Sebastiaan Koppe 
wrote:
It could take a few years indeed, but what will D do in that 
same time window?


What would you like to see?





Re: C++ or D?

2020-12-30 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Wednesday, 30 December 2020 at 21:17:25 UTC, sighoya wrote:
On Wednesday, 30 December 2020 at 21:12:43 UTC, Ola Fosheim 
Grøstad wrote:

(which does not work, but maybe there is some other
way to express it?):


See: 
https://forum.dlang.org/thread/ooxzbrmbrzpsefiro...@forum.dlang.org?page=1


Ok, so basically just add alias:

void foo(alias T)(T!int x) {

Ok. :)




Re: C++ or D?

2020-12-30 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Wednesday, 30 December 2020 at 20:42:49 UTC, jmh530 wrote:

You mean like this

struct Foo(T)
{
T x;
}

void foo(T : Foo!V, V)(T x) {



Not quite, "Foo" would be a template parameter, so something like 
this (which does not work, but maybe there is some other way to 
express it?):



struct Foo(T)
{
T x;
}


void foo(T)(T!int x) {
import std.stdio: writeln;
writeln("here");
}

void main() {
Foo!int x;
foo(x);
}






Re: C++ or D?

2020-12-30 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Wednesday, 30 December 2020 at 19:24:19 UTC, sighoya wrote:
In my eyes, adding proper support for opImplicitCoercion 
enables the reuse of interfaces as typeclasses, yielding more 
potential for idiomatic development than utilizing C++ concepts 
alone.


Not sure what you mean? A D interface is a dynamic runtime 
feature?



Btw, did D ever get to add nested template parameters? I know 
people asked for it a long time ago, but cannot remember if 
that was resolved somehow?


Oh, what's this? Did you mean true Higher Kinded Types (HKT)

```
fun(R,S,T:R=>S)
```



Sort of, in C++ it would be something like this

template class OuterName>
void myfunction(OuterName x){ stuff(); }


That would be great, but they're simply arguing to use alias 
symbols instead. The downside with aliases is however a more 
restricted type inference:


That is clearly a type unification bug. An alias isn't an alias 
if it interferes with type unification!




Re: C++ or D?

2020-12-30 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Wednesday, 30 December 2020 at 18:24:41 UTC, sighoya wrote:
On Wednesday, 30 December 2020 at 14:41:28 UTC, Ola Fosheim 
Grøstad wrote:

Most of the statements are wrong too...
"4732 features, but not a single one you actually want": wrong 
again, C++20 has features that people would like to see in D



Could you elaborate a bit more, please? I'm interested.


Some people in the D community has for a long time wanted 
stack-less coroutines. This is now available in C++20, and maybe 
D can borrow the C++ implementation for LDC? That is an 
interesting possibility for sure.


"template metaprogramming only capable of being understood by 
mensa member": some aspects of C++20 metaprogramming is easier 
than D



That would me interest, too!


The main addition for C++20 is concepts. Basically wrapping up 
ugly tests in a simple template parameter type specifier so that 
you can specify that a template parameter MUST support Addition 
or be a Stack or whatever you want to require with very simple 
syntax. (It also makes it easier to specify tests.)


Btw, did D ever get to add nested template parameters? I know 
people asked for it a long time ago, but cannot remember if that 
was resolved somehow?


Just to say, I think not including multiple inheritance was a 
mistake for Java and all its descendants, though not a big one.


Multiple inheritance needs just a good convention, that's all.


I almost never use multiple inheritance myself, but if you don't 
use it, it does not affect you at all? So how could it be a 
problem to have the option? *shrugs*




Re: C++ or D?

2020-12-30 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Wednesday, 30 December 2020 at 14:17:38 UTC, Rekel wrote:

On Tuesday, 29 December 2020 at 16:13:50 UTC, Imperatorn wrote:

https://ibb.co/syQRs9v


I hope I'm not the only one that thinks 'designers and std lib 
writers unable to name anything correctly' is kind of ironic.

And don't get me started on documentation return values.


Most of the statements are wrong too...

"Forgot null terminator": that is C, not C++.

"undecidable grammer": wrong, not context free != undecidable

"can't execute arbitrary functions at compile time": same as D, 
more or less


"4732 features, but not a single one you actually want": wrong 
again, C++20 has features that people would like to see in D


"unsatisfying standard library": not really, unless you need to 
avoid exceptions


"template metaprogramming only capable of being understood by 
mensa member": some aspects of C++20 metaprogramming is easier 
than D


"multiple-inheritance hell": no idea what this means, MI is 
usually used for the same as D interfaces


"iterators": and ranges...

Anyway, bashing C++ does not get D anywhere. At best it makes D 
users look uninformed.




Re: low-latency GC

2020-12-06 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Sunday, 6 December 2020 at 14:45:21 UTC, Bruce Carneal wrote:
Well, you could in theory avoid putting owning pointers on the 
stack/globals or require that they are registered as gc roots. 
Then you don't have to scan the stack. All you need then is 
write barriers. IIRC


'shared' with teeth?


It was more a hypothetical, as read barriers are too expensive. 
But write barriers should be ok, so a single-threaded incremental 
collector could work well if D takes a principled stance on 
objects not being 'shared' not being handed over to other threads 
without pinning them in the GC.


Maybe a better option for D than ARC, as it is closer to what 
people are used to.





Re: magically a static member on init?

2020-11-17 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Tuesday, 17 November 2020 at 13:24:03 UTC, Kagamin wrote:
On Saturday, 14 November 2020 at 23:30:58 UTC, Adam D. Ruppe 
wrote:

On Saturday, 14 November 2020 at 23:20:55 UTC, Martin wrote:

Is this intentional?


In the current language design, yes.


It's a bug, it breaks data sharing guarantees.


Hah, yes. Init actually should be thread local for this to work 
out...

Ref shared semantics...


Re: Two "references" to dynamic array, why not change both when reallocating?

2020-11-11 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
On Wednesday, 11 November 2020 at 13:30:16 UTC, Simen Kjærås 
wrote:
The short answer is 'because that's how we've chosen to define 
it'. A more involved answer is that changing every reference is 
prohibitively expensive - it would require the equivalent of a 
GC collection on every reallocation, as references to the array 
could exist anywhere in the program, be that on the stack, 
heap, even on other threads. That's the performance side of it.


No... Not true. But either way, D and Golang only have simple 
windows onto memory rather than dynamic array ADTs. That is bad 
for correctness, static analysis and ownership modelling. A 
simple choice, plausible for libraries, but bad for application 
code. If D is going to support non-GC code well, it has to change 
this. C++ got this right btw, where slices can only decrease in 
size.


Then again, extending arrays is generally a bad idea for 
performance in all languages... So try to avoid increasing size 
after initial building.






Re: C++ or D?

2020-11-11 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Tuesday, 10 November 2020 at 01:00:50 UTC, Mark wrote:
I haven't looked into the newest C++. In theory, they might 
have added something helpful in the past years.


I guess you could say that the latest version of C++ allows you 
to write code that is a little bit less verbose than before. C++ 
itself won't really change drastically because of backwards 
compatibility. In my opinion it is not a suitable language for 
hobbyists, as you need to spend a lot of time with it (measured 
in years) to become proficient... and basically, if you don't use 
C++ on a regular basis, there are details that are easy to 
forget. D has some of those issues too, but D can be used more 
like a high level language.





Re: Generic comparison

2020-11-10 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Tuesday, 10 November 2020 at 20:32:40 UTC, Paul Backus wrote:
The compiler infers pure, @nogc, nothrow etc. for template 
functions automatically. It's actually better if you don't add 
them by hand.


Ok, thanks :-).



Re: Generic comparison

2020-11-10 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Tuesday, 10 November 2020 at 17:09:00 UTC, Paul Backus wrote:
bool between(Value, Bound)(auto ref Value value, auto ref Bound 
low, auto ref Bound high)

{
return (low < value) && (value < high);
}

You need `auto ref` because either Bound or Value may have 
copying disabled. Because the function is a template, 
attributes like `scope` will be inferred when applicable 
(modulo compiler bugs).


Interesting, so "auto ref T" is the go-to type specifier for 
generic code then?  I guess I also should conditionally add 
things like pure, nogc, nothrow... I assume I would have to test 
the comparison operator. I actually want to implement


(low <= value) && (value < high)

So I guess I need to test both. But how...? compiles-trait?



Generic comparison

2020-11-10 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
I want to implement a generic function for "a < f(x) < b" that 
will give the same result as "(a < f(x)) && (f(x) < b)" for any 
conceivable mix of types. Except if that "f(x)" should only be 
evaluated once.


Is it sufficient to use "scope ref" in parameters?

I don't want to assume _anything_ about the definition of the 
types and the implementation of the comparison operator (can be 
overloaded).




Re: What is the difference between enum and shared immutable?

2020-10-29 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Thursday, 29 October 2020 at 14:39:31 UTC, H. S. Teoh wrote:
On Thu, Oct 29, 2020 at 09:50:28AM -0400, Steven Schveighoffer 
via Digitalmars-d-learn wrote: [...]

D frequently allows no-op attributes.

[...]

I find that to be a bad smell in terms of language design, 
actually. Either something should be allowed and have a 
definite effect, or it should not be allowed.  Not this murky 
grey area where you can write something and it seems to be 
allowed, but doesn't actually have any effect.


Yes, but that is a tough call. Do you want to catch unintended 
programmer errors or do you want to make it as easy as possible 
to write generic code? I'm in favour of max strictness, but then 
you need to keep the feature set down and make sure it is uniform 
and orthogonal.


But I think it is a bit sad that "shared" isn't enforced so that 
it could lead to actual benefits. Like requiring that globals are 
typed shared and enable thread local garbage collection. E.g. GC 
allocation of non-shared should be on a thread local heap and 
anything shared should be on a global heap.




Re: rt/object.d

2020-10-29 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Thursday, 29 October 2020 at 16:09:00 UTC, Adam D. Ruppe wrote:

The internal rt namespace is also on my website:
http://dpldocs.info/experimental-docs/rt.html

but of course that's private so you can't import it from user 
code.


Thanks, that might be useful later :-).



Re: rt/object.d

2020-10-29 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Thursday, 29 October 2020 at 16:09:10 UTC, kinke wrote:
On Thursday, 29 October 2020 at 16:02:34 UTC, Ola Fosheim 
Grøstad wrote:

I meant the internals like vtable/typeinfo.


https://dlang.org/spec/abi.html#classes


Thanks!


Re: rt/object.d

2020-10-29 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Thursday, 29 October 2020 at 14:06:08 UTC, Adam D. Ruppe wrote:
On Thursday, 29 October 2020 at 14:03:46 UTC, Ola Fosheim 
Grøstad wrote:
The class definition for Object in the runtime object.d is 
"empty". Where can I find a description of the structure and 
fields of "class Object"?


http://dpldocs.info/experimental-docs/object.Object.html


That is the same as the class decl, I meant the internals like 
vtable/typeinfo.


rt/object.d

2020-10-29 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
The class definition for Object in the runtime object.d is 
"empty". Where can I find a description of the structure and 
fields of "class Object"?




Re: What is the difference between enum and shared immutable?

2020-10-29 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Thursday, 29 October 2020 at 08:13:42 UTC, Jan Hönig wrote:
Regarding the shared keyword, I am not sure if immutables are 
shared per default. I thought they are not.


You can test this with is(TYPE1==TYPE2)

is(shared(immutable(int))==immutable(int))



Re: is type checking in D undecidable?

2020-10-22 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Thursday, 22 October 2020 at 19:24:53 UTC, Bruce Carneal wrote:
I dont think it is any easier to prove the "will increase 
faster" proposition than it is to prove the whole thing.


They probably just impose restrictions so that they prove that 
there is reduction and progress over time. One common for 
strategy for proving termination is that something is reduced 
every iteration (or at some points in the program that is passed 
through).






Re: is type checking in D undecidable?

2020-10-22 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Thursday, 22 October 2020 at 18:38:12 UTC, Stefan Koch wrote:
On Thursday, 22 October 2020 at 18:33:52 UTC, Ola Fosheim 
Grøstad wrote:


In general, it is hard to tell if a computation is 
long-running or unsolvable.


You could even say ... it's undecidable :)


:-) Yes, although you can impose restrictions on the language. 
Something that is desirable for type systems. For instance, a 
Prolog program may perhaps not terminate, but all Datalog 
programs will terminate. But is Datalog expressive enough? Not 
sure. Could be cool to try it out though.


Also, some advanced systems might be able to detect that no real 
progress is possible. For example being able to prove that the 
number of "subqueries" to be tried will increase faster than the 
number of "subqueries" that can be resolved.


But this is really the frontier of programming language design...


Re: is type checking in D undecidable?

2020-10-22 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Thursday, 22 October 2020 at 18:24:47 UTC, Bruce Carneal wrote:
Per the wiki on termination analysis some languages with 
dependent types (Agda, Coq) have built-in termination checkers.
 I assume that DMD employs something short of such a checker, 
some combination of cycle detection backed up by resource 
bounds?


"Decidable" is a term that means that there are some cases which 
cannot be decided even if you had near infinite computational 
resources at your disposal. So it is a very theoretical term, and 
not very practical. I don't know what kind of solvers those 
languages use, so I am not exactly sure what they mean by 
"termination checker". In general, it is hard to tell if a 
computation is long-running or unsolvable.




Re: is type checking in D undecidable?

2020-10-22 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Thursday, 22 October 2020 at 17:25:44 UTC, Bruce Carneal wrote:
Is type checking in D undecidable?  Per the wiki on dependent 
types it sure looks like it is.


Even if it is, you can still write something that is decidable in 
D, but impractical in terms of compile time.


You probably mean more advanced type systems where these things 
are expressed more implicitly. Basically type systems where you 
can express and resolve properties related to infinite sizes. D 
does not have such capabilities, so you have to go out of your 
way to end up in that territory in D.






Re: vibe.d / experience / feedback

2020-10-12 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Monday, 12 October 2020 at 11:06:55 UTC, Robert M. Münch wrote:
Go seems to be kept as simple as possible, even if you have to 
write more code. Which is, in the long run, the cheaper and 
smaller burden. No tricks, no surprises... that has a lot of 
merits.


Btw, Go has some major weaknesses related to tricks and surprises:

1. No exceptions... they encourage old 70s-style checking of 
errors everywhere. That makes code much less readable. It is 
possible to roll your own mechanism using their panic() feature, 
but most Go enthusiasts frown upon that. (ignore them, they are 
clueless)


2. Not as strong typing as it should have. Things related to 
interfaces may not be detected until runtime if you get sloppy 
with it. (avoid very generic interfaces)


3. I believe dynamic arrays are reallocated automatically, like 
in D. So in Go, if you extend a dynamic array it will relocate 
and old slices will peek to the old copy:

a := make([]int, 3)
b := a[:]
a = append(a,4,5,6)
b[2] = 3;

fmt.Println(a)
fmt.Println(b)
output:
[0 0 0 4 5 6]
[0 0 3]

So you have to define your own coding standard to avoid such 
issues. Basically, ignore what is touted as Go idioms and create 
a ruleset that makes sense for you.




Re: vibe.d / experience / feedback

2020-10-12 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Monday, 12 October 2020 at 11:21:40 UTC, Robert M. Münch wrote:
Even most people seem to use Go for the web services stuff, I 
think it might be underrate for desktop apps.


Go is good at what it has Go libraries for, and I believe it has 
gotten quite a few over the past years, some that has been 
translated from Python. If you look at some of the 
awesome-go-lists on github then you get a picture of whether it 
will be a good fit for your project.





Re: vibe.d / experience / feedback

2020-10-12 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Monday, 12 October 2020 at 11:06:55 UTC, Robert M. Münch wrote:
Go seems to be kept as simple as possible, even if you have to 
write more code. Which is, in the long run, the cheaper and 
smaller burden. No tricks, no surprises... that has a lot of 
merits.


Yes, it is a good fit for web services with medium sized code 
bases.


Or for Google Cloud Functions. Then you write one program for 
each request handler. This is where I am heading.


The advantage with such a solution is that you can write one 
handler in Python, another in Go and perhaps one in node.js.




Re: vibe.d / experience / feedback

2020-10-11 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Sunday, 11 October 2020 at 11:56:29 UTC, Robert M. Münch wrote:
environment... I don't know about any other language which puts 
all these non-technical aspects on the top of the agenda.


Ada, Java, Eiffel are supposed to.

I'm not sure if Go is a success in that department either. I 
suspect it tanks when programs get large.




Re: What classification should shared objects in qeued thread pools have?

2020-10-01 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Thursday, 1 October 2020 at 00:13:41 UTC, IGotD- wrote:
For example completely lockless algorithms can often be a 
combination of atomic operations and also non-atomic operations 
on data members.


Also, atomic operations on members do not ensure the integrity of 
the struct. For that you need something more powerful 
(complicated static analysis or transactional memory).


I'm very wary of being able to cast away shared, it might 
completely negate all the advertised (memory management) 
optimization opportunities for shared.


For that to work you need some kind of "unshared" or "borrowed" 
like concept.




Re: Memory management

2020-09-29 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Tuesday, 29 September 2020 at 16:03:39 UTC, IGotD- wrote:
That little simple example shows that you don't necessarily 
need to know things in advance in order to have static 
lifetimes. However, there are examples where there is no 
possibility for the compiler to infer when the object goes out 
of scope. Multiple ownership is an obvious example of that.


Seems like a mix of Go and Rust...  People will probably end up 
using array indexes instead of references... Just like in Rust.




Re: enum and const or immutable ‘variable’ whose value is known at compile time

2020-09-17 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Thursday, 17 September 2020 at 10:56:28 UTC, Mike Parker wrote:
Are effectively the same thing, whether it's implemented that 
way or not. So why on earth would a new keyword be necessary?


C++ made enums stricter by "enum class".


Re: Why is BOM required to use unicode in tokens?

2020-09-15 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
On Tuesday, 15 September 2020 at 01:49:13 UTC, James Blachly 
wrote:

I wish to write a function including ∂x and ∂y (these are


You can use the greek letter delta instead:

δ



Re: Is it safe in D to cast pointers to structures like this?

2020-01-14 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Tuesday, 14 January 2020 at 12:05:01 UTC, John Burton wrote:
After years of C++ I have become paranoid about any casting of 
pointers being undefined behavior due to aliasing so want to 
see if :-


FWIW, this is safe and portable in C++20:

https://en.cppreference.com/w/cpp/numeric/bit_cast



1) This is safe to do in D.
2) If not is there anything I can do to make it safe.
3) If not, what is the best approach?


What is legal in C, should in theory be legal in D unless the 
documentation states otherwise as the goal for D is to make 
porting C code to D easy. Hence, type punning through union 
should be ok.


I am not sure what the various D compilers do with aliasing, but 
allowing type punning through pointers can inhibit some 
optimizations.




Re: const and immutable values, D vs C++?

2019-12-05 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
On Thursday, 5 December 2019 at 12:00:23 UTC, Ola Fosheim Grøstad 
wrote:

So basically, templated functions get flow-typing.


But it is not reliable :-(

struct node {int value; node* next;}

node n0 = {1,null};

node mk_node1()(node* n){
node tmp = {2019, n};
return tmp;
}


node mk_node2()(bool ok){
node tmp = {2019, ok ? null : };
return tmp;
}

void main() {
immutable y = mk_node1(null); //succeeds
immutable x = mk_node2(true); //fails
}




Re: const and immutable values, D vs C++?

2019-12-05 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
So basically, templated functions get flow-typing. I guess that 
is a good reason to use templated functions more...


What is the downside? E.g.:

struct node {int value; node* next;}

node mk_node2()(){
node tmp = {2019, null};
return tmp;
}

node mk_node(){
node tmp = {2019, null};
return tmp;
}

void main() {
immutable x = mk_node2(); //succeeds
immutable y = mk_node(); //fails
}



Re: const and immutable values, D vs C++?

2019-12-05 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
On Thursday, 5 December 2019 at 10:41:24 UTC, Ola Fosheim Grøstad 
wrote:

immutable x1 = mk!node1();  //succeeds?
immutable y1 = mk_node1();  //fails


Nevermind, seems like templated functions get stronger coercion, 
like:


 immutable y1 = cast(immutable)mk_node1();

(Also no need to explain that immutable(node0) rewrites all the 
pointer types to immutable, I get it :-)




  1   2   3   >