Re: Should a parser type be a struct or class?
On Wednesday, 17 June 2020 at 11:50:27 UTC, Per Nordlöw wrote: Should a range-compliant aggregate type realizing a parser be encoded as a struct or class? In dmd `Lexer` and `Parser` are both classes. In general how should I reason about whether an aggregate type should be encoded as a struct or class? You have the example of libdparse that shows that using a class can be a good idea [1] [2]. For DCD, the parser overrides a few thing because otherwise completion does not work properly or has scope issues. But TBH there's not many reasons to use a class otherwise. [1] https://github.com/dlang-community/dsymbol/blob/master/src/dsymbol/conversion/package.d#L102 [2] https://github.com/dlang-community/dsymbol/blob/master/src/dsymbol/conversion/package.d#L138
Re: "if not" condition check (for data validation)
On 6/17/20 4:46 PM, Denis wrote:> Is there a cleaner way to implement an
"if not" condition check?
>if ( configfile.isFile && configfile.extension == ".conf", message
) { }
>else
if (isConfigFile(name)) {
// ...
} else {
// ...
}
The following is suitable in many cases:
enforce(isConfigFile(name), format!"%s is not a config file"(name));
// ...
I shortened that in many occasions:
enforceConfigFile(name);
// ...
Of course, depending on the situation it is assert() or assertConfigFile().
Ali
Re: Does std.net.curl: download have support for callbacks?
On Thursday, 11 June 2020 at 06:13:59 UTC, adnan338 wrote: On Thursday, 11 June 2020 at 06:05:09 UTC, adnan338 wrote: I would like to set a callback for the `download()` function but I do not seem to find a way to add a callback to the procedure. [...] I have also been told that Gtk is not thread safe. What does this mean and does it effect me on this scenario? Don't worry, almost ALL GUI FRAMEWORK in the world IS NOT THREAD SAFE, the wellknow Qt and Gtk, and even morden Android and the java Swing. binghoo dang
Re: "if not" condition check (for data validation)
On Thursday, 18 June 2020 at 00:43:40 UTC, Stanislav Blinov wrote: if( ! (configfile.isFile && configfile.extension == ".conf") ) ? That does indeed clean up the compound logic. One is still left with: if( !( if( ! if( !( if( ! : I was hoping to get away from all the `not`s too.
Re: "if not" condition check (for data validation)
On Wednesday, 17 June 2020 at 23:46:54 UTC, Denis wrote: `if` is not a good substitute, because it works in the opposite sense, often requiring lots of `not`s. As a trivial example: assert( configfile.isFile && configfile.extension == ".conf" ) -vs- if ( !configfile.isFile || configfile.extension != ".conf" ) A BETTER SOLUTION ??? I haven't been able to come up with another option that is more efficient yet doesn't sacrifice readability. I would welcome suggestions. Thanks in advance. Denis if( ! (configfile.isFile && configfile.extension == ".conf") ) ?
"if not" condition check (for data validation)
Is there a cleaner way to implement an "if not" condition check?
WHY NOT JUST USE "IF"?
For data validation, code is cleaner and more intelligible if the
condition being checked is written in an affirmative sense; that
is, in the same way that `assert` is written. This is especially
true when `and` and `or` logic is involved. `if` is not a good
substitute, because it works in the opposite sense, often
requiring lots of `not`s. As a trivial example:
assert( configfile.isFile && configfile.extension == ".conf" )
-vs-
if ( !configfile.isFile || configfile.extension != ".conf" )
An `if` statement can be written in the affirmative sense, by
using an empty `then` statement + an `else` statement:
if ( configfile.isFile && configfile.extension == ".conf",
message ) { }
else
But then the logic intuitively feels wrong for an `if`, because
the handler is always in the `else`. When there are only a few
such checks, it might not matter. But when there are a lot of
checks, the code gets ugly (lots of `else`s) and the clutter adds
up.
ORIGINAL SOLUTION
The following solution works and the code is very readable.
However, it has a couple of notable deficiencies.
void unless(T)(T condition, lazy void func ) {
if ( !condition ) func(); }
:
unless( configfile.isFile && configfile.extension == ".conf",
handleIt( _ _ ));
The most obvious shortcomings are:
1. It only works with a handler function. So `continue` and the
like can't be used, for example.
2. It is inefficient, adding an extra function call to every
condition check. Inside a loop, this is cumulative.
A BETTER SOLUTION ???
I haven't been able to come up with another option that is more
efficient yet doesn't sacrifice readability. I would welcome
suggestions.
Thanks in advance.
Denis
Re: Should a parser type be a struct or class?
On Wed, Jun 17, 2020 at 02:32:09PM +, Adam D. Ruppe via Digitalmars-d-learn wrote: > On Wednesday, 17 June 2020 at 14:24:01 UTC, Stefan Koch wrote: > > Parser in dmd does even inherit from Lexer. > > why would a parser ever inherit from a lexer? Because, unlike a regular parser-driven compiler, dmd is a lexer-driven one. :-D T -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a. -- Wouter Verhelst
Re: Should a parser type be a struct or class?
On Wednesday, 17 June 2020 at 14:24:01 UTC, Stefan Koch wrote: Parser in dmd does even inherit from Lexer. why would a parser ever inherit from a lexer?
Re: Should a parser type be a struct or class?
On Wednesday, 17 June 2020 at 11:50:27 UTC, Per Nordlöw wrote: Should a range-compliant aggregate type realizing a parser be encoded as a struct or class? In dmd `Lexer` and `Parser` are both classes. In general how should I reason about whether an aggregate type should be encoded as a struct or class? I would say a struct. Parser in dmd does even inherit from Lexer. It seems to be a quirky design. Especially for multi-threaded parsing you might want to have more control over memory layout than classes usually give you.
Re: Should a parser type be a struct or class?
On Wed, Jun 17, 2020 at 11:50:27AM +, Per Nordlöw via Digitalmars-d-learn wrote: > Should a range-compliant aggregate type realizing a parser be encoded > as a struct or class? Preferably a struct IMO, but see below. > In dmd `Lexer` and `Parser` are both classes. Probably for historical reasons. > In general how should I reason about whether an aggregate type should > be encoded as a struct or class? 1) Does it need runtime polymorphism? If it does, use a class. If not, probably a struct. 2) Does it make more sense as a by-value type, or a by-reference type? In several of my projects, for example, I've had aggregate types start out as structs (because of (1)), but eventually rewritten as (final) classes because I started finding myself using `ref` or `&` everywhere to get by-reference semantics. My rule-of-thumb is basically adopted from TDPL: a struct as a "glorified int" with by-value semantics, a class is a more traditional OO object. If my aggregate behaves like a glorified int, then a struct is a good choice. If it behaves more like a traditional OO encapsulated type, then a class is probably the right answer. T -- Many open minds should be closed for repairs. -- K5 user
Re: Link error triggered by `dub test` but not by `dub build --unittest`
On Wednesday, 17 June 2020 at 12:12:24 UTC, Per Nordlöw wrote:
On Tuesday, 16 June 2020 at 12:21:26 UTC, Per Nordlöw wrote:
when
dub test
doesn't?
I'm trying to reduce it through
dustmite phobos-next "dub test 2>&1 | grep -F
'_D6object10_xopEqualsFMxPvMxQeZb'"
Is this the best way to use dustmite in this case?
Was reduced to rational.d with content
module nxt.rational;
Rational!(I1) rational(I1, I2)(I1 , I2)
{
return typeof(return)();
}
struct Rational(Int)
{
bool opEquals(Rhs)(Rhs _) {}
}
@nogc unittest
{
auto _ = rational(1, 2);
}
When I remove
bool opEquals(Rhs)(Rhs _) {}
error goes away. Seems like a bug to me.
Re: How to compile to .bin/.iso format
On Wednesday, 17 June 2020 at 12:39:11 UTC, FeepingCreature wrote: On Wednesday, 17 June 2020 at 12:30:24 UTC, Quantium wrote: Hi all! I have a programm in D (The simplest OS), which should be compiled into .bin or .iso format to be possible to run it on VirtualBox. How can I compile it to .bin / .iso format and which compiler should I use? Try this page? https://wiki.osdev.org/D_Bare_Bones combined with https://dlang.org/phobos/core_volatile.html to replace volatile. Update: Tried and it works with ldc 1.20.1 (2.090.1) at least. The LDC version of the command is `ldc2 -betterC -m32 -c kernel.main.d -ofkernel.main.o -g`.
Re: How to compile to .bin/.iso format
On Wednesday, 17 June 2020 at 12:30:24 UTC, Quantium wrote: Hi all! I have a programm in D (The simplest OS), which should be compiled into .bin or .iso format to be possible to run it on VirtualBox. How can I compile it to .bin / .iso format and which compiler should I use? Try this page? https://wiki.osdev.org/D_Bare_Bones combined with https://dlang.org/phobos/core_volatile.html to replace volatile.
Re: Should a parser type be a struct or class?
On Wednesday, 17 June 2020 at 11:50:27 UTC, Per Nordlöw wrote:
Should a range-compliant aggregate type realizing a parser be
encoded as a struct or class? In dmd `Lexer` and `Parser` are
both classes.
In general how should I reason about whether an aggregate type
should be encoded as a struct or class?
What's a range-compliant aggregate type? Ranges are typically
views of someone else's data; an owner of the data woulnd't store
mutable iterators, and won't be a range. For that reason also,
ranges are structs, as most of them are thin wrappers over a set
of iterators with an interface to mutate them.
If you *really* need runtime polymorphism as provided by the
language - use a class. Otherwise - use a struct. It's pretty
straightforward. Even then, in some cases one can realize their
own runtime polymorphism without classes (look at e.g. Atila
Neves' 'tardy' library).
It's very easy to implement a lexer as an input range: it'd just
be a pointer into a buffer plus some additional iteration data
(like line/column position, for example). I.e. a struct. Making
it a struct also allows to make it into a forward range, instead
of input range, which is useful if you need lookahead:
struct TokenStream
{
this(SourceBuffer source)
{
this.cursor = source.text.ptr;
advance(this);
}
bool empty() const
{
return token.type == TokenType.eof;
}
ref front() return scope const
{
return token;
}
void popFront()
{
switch (token.type)
{
default:
advance(this);
break;
case TokenType.eof:
break;
case TokenType.error:
token.type = TokenType.eof;
token.lexSpan = LexicalSpan(token.lexSpan.end,
token.lexSpan.end);
break;
}
}
TokenStream save() const
{
return this;
}
private:
const(char)* cursor;
Location location;
Token token;
}
, where `advance` is implemented as a module private function
that actually parses source into next token.
DMD's Lexer/Parser aren't ranges. They're ourobori.
Re: Should a parser type be a struct or class?
On Wednesday, 17 June 2020 at 11:50:27 UTC, Per Nordlöw wrote: Should a range-compliant aggregate type realizing a parser be encoded as a struct or class? In dmd `Lexer` and `Parser` are both classes. In general how should I reason about whether an aggregate type should be encoded as a struct or class? The heuristic I use is 'do I need polymorphism?' If no, it's a struct. Another thing that may be worth considering is reference semantics. The latter is easy to do with a struct, while polymorphism is generally a class-only thing (but check out Tardy, which Atila Neves recently posted in the Announce group). I would say I basically never use classes in D - pointers and arrays give me all the reference semantics I need, and polymorphism I almost never need. -- Simen
How to compile to .bin/.iso format
Hi all! I have a programm in D (The simplest OS), which should be compiled into .bin or .iso format to be possible to run it on VirtualBox. How can I compile it to .bin / .iso format and which compiler should I use?
Re: Link error triggered by `dub test` but not by `dub build --unittest`
On Tuesday, 16 June 2020 at 12:21:26 UTC, Per Nordlöw wrote: when dub test doesn't? I'm trying to reduce it through dustmite phobos-next "dub test 2>&1 | grep -F '_D6object10_xopEqualsFMxPvMxQeZb'" Is this the best way to use dustmite in this case?
Should a parser type be a struct or class?
Should a range-compliant aggregate type realizing a parser be encoded as a struct or class? In dmd `Lexer` and `Parser` are both classes. In general how should I reason about whether an aggregate type should be encoded as a struct or class?
Re: Link error triggered by `dub test` but not by `dub build --unittest`
On Tuesday, 16 June 2020 at 12:21:26 UTC, Per Nordlöw wrote: All the linker errors originate from zio.d but zio.d has its unittests disabled so how come this fails to link? zio.d is not the source of the problem. Something else is. The common denominator seems to be that the builtins xopEqual and xopCmp aren't defined upon linking. These seem to be generated by dmd. Can anybody explain what's going on here?
