Re: IDE for D? Recommendations?
"Tim Matthews" wrote in message news:hbtlah$2iu...@digitalmars.com... > AJ wrote: >> Anyone have recommendations for which IDE to use to do an evaluation of D >> with? I don't need powerful capabilities as I'm just looking to write >> some code and get a feel for some things in D. A bundle would be great. >> Also, I think it would be fun to look at the libraries during the eval. >> "Eval" is too strong... I just wanna play around with D a little bit in >> my spare time. If I can't be up an running in less than an hour, >> including any reading necessary to get set up, I'll have to save it for >> another time. I definitely don't want to be at a commandline prompt. All >> comments/recommendations/opinions welcomed. (Thanks in advance). > > Posts like thismostly unnecessary (and could be place in d.learn to > stay out of the way). > > http://prowiki.org/wiki4d/wiki.cgi?EditorSupport#IDEs > http://stackoverflow.com/questions/50179/an-ide-for-d > http://stackoverflow.com/questions/814142/whats-the-best-ide-for-digitalmars-d-programming > http://stackoverflow.com/questions/394757/is-there-an-ide-for-d-with-integrated-debugger > No offense, I just like to pretend I am not dying, cuz it really fucking sucks a lot sometimes.
Re: No header files?
"Leandro Lucarella" wrote in message news:20091023125658.ga23...@llucax.com.ar... > AJ, el 22 de octubre a las 22:08 me escribiste: >> > I'm still not clear on exactly what you plan on doing. >> >> "Traditional" (read C/C++ like) software development. >> >> > If you plan on generating the function prototypes >> >> Nope. I plan on hand-crafting header files before I create any >> implementation files. >> >> > in a .d file and filling out the bodies later, go for it. >> >> Oh, by "generating" (bad choice of word), you meant "writing". Yes I do. >> >> > If you plan on hand writing the .di file >> >> Ooops! No I don't! Yes, I will be "modeling" via header files. > > May I suggest something? If you want to "model via header files", write .d > files with just declarations (skip implementations). You'll end up with > hand written .di (headers) files, but in a .d files, so you can still > automatically generate .di files from it. Use the .d files as an import in > other modules (i.e., don't provide hand written .di files only). Then, > when you want to start implementing your "model", just add the bodies to > the functions in the "modeled" .d file. > > The effect in the development process is the same as hand writing .h files > and progressively fill the .cpp files with the implementation, but you are > doing all the work in just *one* place (the .cpp/.d files) and generating > the headers files (.h/.di) from that. > > What problems do you find in that scheme? > > -- > Leandro Lucarella (AKA luca) http://llucax.com.ar/ > -- > GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) > -- > Soy como una mosca, parada en el agua. > Y vos sos un transatlántico, querés nadar a mi lado. > Y me estás ahogando. I'm convinced: D is not me.
Re: No header files?
On 24/10/2009 01:56, Simen Kjaeraas wrote: Yigal Chripun wrote: On 22/10/2009 18:52, BCS wrote: I'm cynical enough that I'd bet if D switches to a "smarter lib format" a lot of people would manage to forget the documentation. With the current system, the library must be shipped with, at a minimum, a human readable list of prototypes. without proper documentation people will have no way to know how to use such libraries. given that D has DDoc to automate this process I'd say it'll encourage developers to provide proper documentation instead of just saying - go read the headers/source. Wild ideas to make people document code: 1) Make DDoc generation the default, turn off by command line switch. 2) Issue a warning (or even error) when a public function is uncommented. -- Simen that's too much I think. DDoc should be separated from the compiler and just use the compiler's XML/Json output to generate documentation. Such a separate DDoc program can issue documentation warnings (just like doxygen can).
Re: stack frame optimization problem
Okay, between gdb and obj2asm I've been able to figure out that the address
placed in EAX in the following instructions...
mov EAX, jumpTo;
jmp EAX;
is actually the address of the initialization function for jumpTo...
byte* jumpTo = &jumpHere;
which is named _D9conductor6jumpToPg. Execution then ends up segfaulting on a
(bad) instruction in function _moduleinfo_array.
So I'm not sure if the wrong address is being stored in jumpTo or if I'm simply
not correctly dereferencing it. Ultimately I need to know the offset from
function pointers to the point at which the prolog has completed and execution
of the main function body begins. I'm attempting to discover the offset by
using a dummy function containing a "jumpHere:" label and subtracting the
function address from the label address. Is there a better way to do this?
Thanks for the suggestions I've received. I'm learning a lot!
sprucely Wrote:
> This works with g++ and inline ATT assembly, but I have had no such luck in
> D. I have many simple functions that need to be executed sequentially and
> have identical stack frames. To avoid the overhead of setting up and tearing
> down the stack frames I want to jmp from the body of one function to the body
> of the next. A simplified example...
>
> extern(C) byte jumpHere;
>
> byte* jumpTo = &jumpHere;
>
> void f1()
> {
> asm
> {
> //jmp dword ptr jumpTo;
> mov EAX, jumpTo;
> jmp EAX;
> //jmp [EAX]
> }
> }
>
> void f2()
> {
> asm{jumpHere:;}
> }
>
> No matter what I try I get a segfault. My assembly skills are very limited.
> I'm not using the naked keyword yet, because I want to get a proof-of-concept
> working first. Anyone see anything wrong with this? Any suggestions?
Re: OT: Hats... Mostly unnecessary?
"Christopher Wright" wrote in message news:hbt9gn$1r4...@digitalmars.com... > It had a button. I'm on the edge of my seat...I must know more about this wondrous hat!
Re: IDE for D? Recommendations?
AJ wrote: Anyone have recommendations for which IDE to use to do an evaluation of D with? I don't need powerful capabilities as I'm just looking to write some code and get a feel for some things in D. A bundle would be great. Also, I think it would be fun to look at the libraries during the eval. "Eval" is too strong... I just wanna play around with D a little bit in my spare time. If I can't be up an running in less than an hour, including any reading necessary to get set up, I'll have to save it for another time. I definitely don't want to be at a commandline prompt. All comments/recommendations/opinions welcomed. (Thanks in advance). Posts like thismostly unnecessary (and could be place in d.learn to stay out of the way). http://prowiki.org/wiki4d/wiki.cgi?EditorSupport#IDEs http://stackoverflow.com/questions/50179/an-ide-for-d http://stackoverflow.com/questions/814142/whats-the-best-ide-for-digitalmars-d-programming http://stackoverflow.com/questions/394757/is-there-an-ide-for-d-with-integrated-debugger
Re: this() not executing code on structs
On Sat, 24 Oct 2009 03:28:02 +0400, Denis Koroskin <2kor...@gmail.com>
wrote:
On Fri, 23 Oct 2009 19:40:33 +0400, Andrei Alexandrescu
wrote:
Denis Koroskin wrote:
On Fri, 23 Oct 2009 18:46:47 +0400, Andrei Alexandrescu
wrote:
Don wrote:
Bartosz Milewski wrote:
Andrei Alexandrescu Wrote:
this() { myCount = count++; } // ERROR
It's worse than that. Try this:
struct foo {
this(int dummy = 0) { writeln("Default constructor");}
}
foo x = foo();
Nothing gets printed. If default constructors are disallowed, so
should constructors with all parameters defaulted.
Ouch.
It's because it's interpreting foo() as a struct literal.
If a struct has any constructors, struct literals should be disabled.
http://d.puremagic.com/issues/show_bug.cgi?id=3438
The more I think of it, the more imperious it becomes that we allow
default constructors that execute code. The main question is what to
do about .init.
Andrei
I'd suggest ditching it and enforce explicit member initialization
(unless a variable is nullable). This will also remove a lot of bloat
from executables.
I don't understand. The problem right now is that even of all fields
are explicitly intialized, e.g.
struct A {
Widget x = null;
double d = 0;
int i = -1;
}
there is still no ability to execute code upon initialization, e.g.
force A to contain a non-null Widget.
Andrei
Yes, I was talking about a different scheme, where default ctors are
allowed. They aren't allowed now but we are talking about things we can
change/improve, right?
I mean there is no _real_ need for T.init, just malloc()'ate some memory
and call the __ctor on it. Struct members default values would be
converted into runtime initialization expressions like this:
struct A
{
this(Args)(Args args) // may be an empty set of arguments
{
// the following lines are inserted automatically
x = null;
d = 0;
i = -1;
// user-defined code follows
i = 42;
}
Widget x = null;
double d = 0;
int i = -1;
}
Optimization pass would eliminate double initialization (in the case
about i would be initialized straight to 42)
This scheme works fine for C++, and it would fit languages that don't
support MI even better.
I believe D's approach with init is a bit easier to understand (rules are
less complicated), but it is also not very efficient: a few stores/pushes
are faster than memcpy'ing few bytes in most cases (minor but still). And
an additional bloat it introduces is also not very welcome, of course.
While I'm not a idealizing C++ object initialization scheme, I do think it
is sound (even though it is complicated). Some variation of it may be well
suitable for D.
I made the following post a while ago
(http://www.digitalmars.com/d/archives/digitalmars/D/D_programming_practices_object_construction_order_85468.html),
it may interest you as I believe it is relevant to this discussion.
Unfortunately no one has made any comments about it (is it silly, or just
nobody cares?).
Re: Targeting C
grauzone wrote:
Andrei Alexandrescu wrote:
Pelle Månsson wrote:
Andrei Alexandrescu wrote:
Yigal Chripun wrote:
On 23/10/2009 13:02, bearophile wrote:
Chris Nicholson-Sauls:
I prefer this (Scala):
list = list ++ (0 to 10)
That's quite less readable. Scala sometimes has some unreadable
syntax. Python has taught me how much useful a readable syntax is :-)
Designing languages requires to find a balance between several
different and opposed needs.
Bye,
bearophile
how about this hypothetical syntax:
list ~= [0..10];
I'm not sure what the type of "list" is supposed to be, but this
works today for arrays:
list ~= array(iota(0, 10));
Andrei
What does iota mean?
http://www.digitalmars.com/d/2.0/phobos/std_range.html#iota
This link jumps straight to:
Take!(Sequence!("a.field[0] + n *
a.field[1]",Tuple!(CommonType!(B,E),S))) iota(B, E, S)(B begin, E end, S
step);
Wow, please tell me this is a ddoc malfunction. I mean, that thing left
to iota is supposed to be a type?
(OK, it _is_ a malfunction, but that thing is still supposed to be... a
type?)
Well what was I supposed to do? It was either define another type Iota,
or reuse existing types. I chose to reuse.
Andrei
Re: Semicolons: mostly unnecessary?
On Fri, Oct 23, 2009 at 4:54 PM, Yigal Chripun wrote: > On 23/10/2009 19:41, bearophile wrote: >> >> Yigal Chripun: >> >>> The trade-off here is obvious: if you use line continuations like >>> in python they would be very rare but would not be automatic and >>> consistent when you do need to use them. >> >> In my Python code (or in good code you may find around, like in some >> modules of the std library) you may have a hard time finding few line >> continuations. Generally you can avoid them putting code in >> parentheses. And if/when you want to use them it's simple. So I think >> you are wrong. >> >> Bye, bearophile > > Nothing you said contradicts what I said. > The fact that they are rare in python means that you need to think if and > when you need to use them whereas in c/c++/d/etc you use semicolons > consistently throughout the code so adding them is an automatic action that > requires no thought. You don't really have to keep it much in mind. Either your editor will tell you you've done something wrong by indenting things in an unexpected way, or if not, the parser will tell you when it does its pass to byte-compile the source. > here's an analogy: > there's a speed limit set by law inside cities so any driver with little > experience will automatically slow down when entering a city. that speed > limit becomes an automatic habit you don't need to think about. > however when you see a sign with a different speed limit you do need to > process that info in the brain and conscientiously change your speed. Think of the code editor / byte-compilation engine as the buddy in the passenger seat telling you to slow down. Its not a problem when you have such a buddy. --bb
Re: Targeting C
Andrei Alexandrescu wrote:
Pelle Månsson wrote:
Andrei Alexandrescu wrote:
Yigal Chripun wrote:
On 23/10/2009 13:02, bearophile wrote:
Chris Nicholson-Sauls:
I prefer this (Scala):
list = list ++ (0 to 10)
That's quite less readable. Scala sometimes has some unreadable
syntax. Python has taught me how much useful a readable syntax is :-)
Designing languages requires to find a balance between several
different and opposed needs.
Bye,
bearophile
how about this hypothetical syntax:
list ~= [0..10];
I'm not sure what the type of "list" is supposed to be, but this
works today for arrays:
list ~= array(iota(0, 10));
Andrei
What does iota mean?
http://www.digitalmars.com/d/2.0/phobos/std_range.html#iota
This link jumps straight to:
Take!(Sequence!("a.field[0] + n *
a.field[1]",Tuple!(CommonType!(B,E),S))) iota(B, E, S)(B begin, E end, S
step);
Wow, please tell me this is a ddoc malfunction. I mean, that thing left
to iota is supposed to be a type?
(OK, it _is_ a malfunction, but that thing is still supposed to be... a
type?)
Re: Targeting C
Andrei Alexandrescu wrote:
Pelle Månsson wrote:
Andrei Alexandrescu wrote:
Yigal Chripun wrote:
On 23/10/2009 13:02, bearophile wrote:
Chris Nicholson-Sauls:
I prefer this (Scala):
list = list ++ (0 to 10)
That's quite less readable. Scala sometimes has some unreadable
syntax. Python has taught me how much useful a readable syntax is :-)
Designing languages requires to find a balance between several
different and opposed needs.
Bye,
bearophile
how about this hypothetical syntax:
list ~= [0..10];
I'm not sure what the type of "list" is supposed to be, but this
works today for arrays:
list ~= array(iota(0, 10));
Andrei
What does iota mean?
http://www.digitalmars.com/d/2.0/phobos/std_range.html#iota
This link jumps straight to:
Take!(Sequence!("a.field[0] + n *
a.field[1]",Tuple!(CommonType!(B,E),S))) iota(B, E, S)(B begin, E end, S
step);
Wow, please tell me this is a ddoc malfunction. I mean, that thing left
to iota is supposed to be a type?
Irony minded. I'm destroyed.
Andrei
Re: No header files?
On 23/10/2009 21:52, Steven Schveighoffer wrote: On Fri, 23 Oct 2009 15:50:18 -0400, Walter Bright wrote: Yigal Chripun wrote: Shared libraries are inherently not portable from system to system. only if you consider dlls and so. Java jars are portable. so do .net assemblies. Jars and .nets are not executable code. Dlls and shared libraries are. .net assemblies built by visual studio are packaged as dlls. Although I don't know exactly how they are executed, I'm sure it's some sort of bytecode. Just saying... -Steve http://www.programmersheaven.com/2/FAQ-DOTNET-DOTNET-Assembly-Explained
Re: No header files?
On 23/10/2009 21:52, Steven Schveighoffer wrote: On Fri, 23 Oct 2009 15:50:18 -0400, Walter Bright wrote: Yigal Chripun wrote: Shared libraries are inherently not portable from system to system. only if you consider dlls and so. Java jars are portable. so do .net assemblies. Jars and .nets are not executable code. Dlls and shared libraries are. .net assemblies built by visual studio are packaged as dlls. Although I don't know exactly how they are executed, I'm sure it's some sort of bytecode. Just saying... -Steve from wikipedia: In the Microsoft .NET framework, an assembly is a partially compiled code library for use in deployment, versioning and security. There are two types: process assemblies (EXE) and library assemblies (DLL). A process assembly represents a process which will use classes defined in library assemblies. .NET assemblies contain code in CIL, which is usually generated from .NET languages, and then compiled into machine language at runtime by the CLR just-in-time compiler. An assembly can consist of one or more files. Code files are called modules. An assembly can contain more than one code module and since it is possible to use different languages to create code modules it is technically possible to use several different languages to create an assembly. I read somewhere (I can't seem to find the reference ATM) that if you install a .net app with signed assemblies, the installer will compile the assemblies into native executable code (ahead-of-time) and will store them in a system cache. all the system assemblies are pre-compiled like this.
Re: this() not executing code on structs
Steven Schveighoffer wrote:
On Thu, 22 Oct 2009 12:50:21 -0400, grauzone wrote:
dsimcha wrote:
== Quote from grauzone (n...@example.net)'s article
Andrei Alexandrescu wrote:
I'd really like to know why "scope x = new X();" is "unsafe", while
encouraging doing exactly the same with structs seems to be a perfectly
fine idea. Allocating structs on the stack is obviously not any safer
than with classes. I don't remember the exact reasons why you wanted to
turn "scope" into a library feature, but I think I remember something
about discouraging it for safety reasons; please forgive me is this is
wrong.
Because classes in D are always passed by pointer. (Technically
references, but
really they're just pointers under the hood.) Returning a scope
(stack-allocated)
class from a function is equivalent to escaping a pointer to a stack
variable.
Returning a struct is done by value, just like returning an int.
(I'm talking about scope classes as declared in "scope class T { ... }")
Your original question was about the statement "scope x = new X()",
which can be done on any type of class, even non-scope ones.
I mentioned that "scope class T" thing in my original post too.
But you can't return scope classes from a function. You can't pass
them as ref parameters either. They're designed to be safe.
On the other hand, you can pass struct pointers all the way you want
around, and it's damn unsafe.
I don't get this "structs are safe because they are value types"
argument anyway, because the this pointer for structs is a
pointer/reference anyway. If it's trivial to break that "safety", can
you really call it "safety"?
Passing struct pointers is not always the norm. Passing class
references *is* the norm (and actually the only way), even for scope
classes, so there is much more chance for escape.
You can end up passing hidden pointers quickly, because a struct's this
is a reference, and there are ref parameters and even ref returns. But
Andrei is convinced that he can make passing refs safe, and as soon as
they're safe, you're probably right.
Scope is really a dangerous hack to allocate a *reference type* on
the stack.
It's dangerous and kludgey, but in a performance-oriented language
it's a
necessary evil.
You could say the same about structs.
You have to go out of your way to pass a struct by reference. You
*can't* possibly pass a class by value, so they are more dangerous.
In order to make scope safer, it has to be a type modifier in addition
to a storage class, so the compiler can make reasonable decisions (like
disallowing implicit casting to a non-scope version).
That would have been possible. That type modifiers is already there and
is partially implemented. But Andrei seems to have decided to go another
way (using structs instead of classes), and this will become a useless
feature. So I hope it will be removed to make the language less bloater.
Why do all objects have monitor pointers anyway? The idea, that every
object can act as lock, is a really bad one. But this is off-topic...
All objects have a *placeholder* for a lock, which isn't allocated until
the object is locked for the first time. It's a very pervasive idea in
other successful languages like Java and C#. Having used it extensively
in C#, I find it very easy to use and well designed.
I found it never useful. Even more, implicitly using an object as a lock
makes the locking scheme more unclear ("which object is a lock and which
isn't? I can't tell anymore!"), and I see lots of code that does the
"Object lock = new Object();" thing to get rid of this confusion.
Being able to use an object as lock looks like a nice, naive idea from
the early days of multithreading, but it's obsolete now.
Even if the allocation of the mutex is done lazily on demand, why add
overhead to *all* light weight objects for such a useless thing?
However, in C#, there is support for conditions on objects as well,
which isn't "builtin" for D. IMO, mutexes without conditions is
severely limiting. The library condition variables aren't as nice as
C#'s builtin conditions.
I always wondered how D could claim to make "big steps" into
multithreading, without having any mechanism to signal other threads; it
only had locks. The library condition variables from D runtime just
fixed this hole from "outside".
-Steve
Re: No header files?
Yigal Chripun wrote: On 22/10/2009 18:52, BCS wrote: I'm cynical enough that I'd bet if D switches to a "smarter lib format" a lot of people would manage to forget the documentation. With the current system, the library must be shipped with, at a minimum, a human readable list of prototypes. without proper documentation people will have no way to know how to use such libraries. given that D has DDoc to automate this process I'd say it'll encourage developers to provide proper documentation instead of just saying - go read the headers/source. Wild ideas to make people document code: 1) Make DDoc generation the default, turn off by command line switch. 2) Issue a warning (or even error) when a public function is uncommented. -- Simen
Re: Semicolons: mostly unnecessary?
On 23/10/2009 19:41, bearophile wrote: Yigal Chripun: The trade-off here is obvious: if you use line continuations like in python they would be very rare but would not be automatic and consistent when you do need to use them. In my Python code (or in good code you may find around, like in some modules of the std library) you may have a hard time finding few line continuations. Generally you can avoid them putting code in parentheses. And if/when you want to use them it's simple. So I think you are wrong. Bye, bearophile Nothing you said contradicts what I said. The fact that they are rare in python means that you need to think if and when you need to use them whereas in c/c++/d/etc you use semicolons consistently throughout the code so adding them is an automatic action that requires no thought. here's an analogy: there's a speed limit set by law inside cities so any driver with little experience will automatically slow down when entering a city. that speed limit becomes an automatic habit you don't need to think about. however when you see a sign with a different speed limit you do need to process that info in the brain and conscientiously change your speed.
Re: [OT] What should be in a programming language?
On 23/10/2009 19:50, Jason House wrote:
Yigal Chripun Wrote:
transitive const and everything is const by default, immutable as
part of the concurrency ownership design, functions would be
defined as in ML: they take one tuple argument and return one tuple
argument
I like scala's concept of multiple input tuples, and the freedom to
use () or {} when specifying a tuple. I might be slightly stricter
with how each tuple is used such that the library writer says which
form is allowed. This has the awesome side effects of making
libraries look like part of the language.
i don't know about this specific feature of Scala. in D you can pass a
(type) tuple to a function and it is auto flattened to the arg list.
i.e.
void foo(int, int);
Tuple!(int, int) a = ...;
foo(a);
in ML, the arg list *is* a tuple so there's no need for an auto-flatten.
you can always nest tuples so it's trivial to have multiple tuples as
arguments.
example (not tested):
fun foo (a, (b, c)) = a*b + a*c
let bar = foo(3, (4, 5))
foo's signature would be: ('a, ('a, 'a)) -> ('a)
i don't like the #if, etc idea and would prefer a proper AST macro
system with proper hygiene
The AST macro stuff predates my participation on this list. Have any
good links explaining how it works? I've been thinking of allowing
expressions, statements (and friends) as object types and then
allowing mixing in of those objects...
#var declareX = Statement ("int x=3"); #mixin declareX;
... or something along those lines...
http://en.wikipedia.org/wiki/Nemerle
http://en.wikipedia.org/wiki/Hygienic_macro
here's a quick summary of how it should work/look like:
macros are written in the same language, no #if, no static if.
you write regular looking functions in plain code. those macros are
compiled separately into loadable libs that you can specify for the
compiler to load. the language has syntax to [de]compose AST.
I'd remove static from the language completely and instead would
have metaclasses.
I agree with no statics. What are metaclasses? I like how scala
defines singletons for statics (object in scala type declaration)
there are different models for this and this also relates to the macro
system above. here's one model (used in smalltalk)
class Foo {
int a;
void foo();
}
the compiler will generate for Foo a singleton of the type 'Foo which
contains all the information about Foo. for example, it'll contain the
list of functions for Foo instances. this is the same as in D - in D we
have Typeinfo structs that contain vtables.
class Bar {
int a;
static void foo();
}
in compiled languages (c++/d) this is done statically (foo is a global
function in the assembly)
in smalltalk the previous mechanism is [re]used:
we have class Bar which defines it's instances
we have class 'Bar that defines Bar
we have class ''Bar that defines 'Bar
we have class Class that defines ''Bar
total of 5 levels which are required to have class shared functions/state
other OOP changes - better separation between sub-typing and
sub-classing:
type interfaceA extends interfaceB, interfaceC {} implementation
implA extends implB, implC implements interfaceA, interfaceD{}
auto obj = interfaceA.new(); // returns an implementation, e.g.
implA
ionstead of the classic: class A {} class B: A {}
we'll have: type A {} type B extends A {} implementation A
implements A{} implementation B extends implementation A implements
B {}
There seems to be redundency here. Why would you/others want that?
Super verbose code makes it tough to attract users.
I was trying to convey semantics here rather than syntax. deriving a
class from a base class is a poor way to design code and I want to
separate two orthogonal issues -
a. subtyping and polymorphism
b. reuse of code/ implementation
everything is an object and no special treatment for specific
types
I don't think "everything is an object" works under the hood, but I
do like making that transparent. A lot of the items allow transparent
use of reference and value types (scope by default unless explicitly
marked/allocated, and transitive const by default unless passed by
ref)
c style built in types expose an implementation detail that should be
encapsulated and hidden under the hood as you say.
there should be no syntactic difference between an int and a user
defined type.
for example I should be able to do:
struct foo : int {}
Re: Semicolons: mostly unnecessary?
On Fri, 23 Oct 2009 22:07:42 +0200, Nick Sabalausky wrote: "Walter Bright" wrote in message news:hbt1sv$165...@digitalmars.com... Consider the fragment: Ifthepointisntplainobviousfromtheabovefewersymbols Where else could the spaces possibly go? There's only one possible way: Ift hep oint is NT, pla I nob VI O' U.S. Fromt he, a bovef. Ew! Ers y m bols! It's obviously a note from a crazy person. Nonono. Those who have studied cryptanalysis know that the right way would be: IFTHE POINT ISNTP LAINO BVIOU SFROM THEAB OVEFE WERSY MBOLS -- Simen
Re: this() not executing code on structs
On Fri, 23 Oct 2009 19:40:33 +0400, Andrei Alexandrescu
wrote:
Denis Koroskin wrote:
On Fri, 23 Oct 2009 18:46:47 +0400, Andrei Alexandrescu
wrote:
Don wrote:
Bartosz Milewski wrote:
Andrei Alexandrescu Wrote:
this() { myCount = count++; } // ERROR
It's worse than that. Try this:
struct foo {
this(int dummy = 0) { writeln("Default constructor");}
}
foo x = foo();
Nothing gets printed. If default constructors are disallowed, so
should constructors with all parameters defaulted.
Ouch.
It's because it's interpreting foo() as a struct literal.
If a struct has any constructors, struct literals should be disabled.
http://d.puremagic.com/issues/show_bug.cgi?id=3438
The more I think of it, the more imperious it becomes that we allow
default constructors that execute code. The main question is what to
do about .init.
Andrei
I'd suggest ditching it and enforce explicit member initialization
(unless a variable is nullable). This will also remove a lot of bloat
from executables.
I don't understand. The problem right now is that even of all fields are
explicitly intialized, e.g.
struct A {
Widget x = null;
double d = 0;
int i = -1;
}
there is still no ability to execute code upon initialization, e.g.
force A to contain a non-null Widget.
Andrei
Yes, I was talking about a different scheme, where default ctors are
allowed. They aren't allowed now but we are talking about things we can
change/improve, right?
I mean there is no _real_ need for T.init, just malloc()'ate some memory
and call the __ctor on it. Struct members default values would be
converted into runtime initialization expressions like this:
struct A
{
this(Args)(Args args) // may be an empty set of arguments
{
// the following lines are inserted automatically
x = null;
d = 0;
i = -1;
// user-defined code follows
i = 42;
}
Widget x = null;
double d = 0;
int i = -1;
}
Optimization pass would eliminate double initialization (in the case about
i would be initialized straight to 42)
Re: Private enum members + Descent
Sorry; subject line mod'ed just so Ary doesn't miss it.
> enum Color { private UNINITIALIZED = -1, RED, GREEN, BLUE }
> (btw. Interestingly, typing this code into Eclipse with the Descent plug-in
> causes a Java out of heap space malfunction.)
Private enum members
My google search for
private "enum member" site:digitalmars.com
come up with nothing much so presumably this hasn't been discussed before.
There may be a valid use-case for being allowed to selectively mark
some enum members as being private, such as
enum Color {
private UNINITIALIZED = -1,
RED, GREEN, BLUE
}
(The above doesn't work in D1. Haven't tried D2 though.)
(btw. Interestingly, typing this code into Eclipse with the Descent plug-in
causes a Java out of heap space malfunction.)
Is this a valid use-case? What do you think?
-- Justin Johansson
Re: Semicolons: mostly unnecessary?
Andrei Alexandrescu wrote: therapistswhopreachedonweeknights Not a problem. Use surrounding context.
Re: [OT] Re: Targeting C
On Fri, 23 Oct 2009, Ary Borenszweig wrote: > Andrei Alexandrescu wrote: > > Steven Schveighoffer wrote: > > > On Fri, 23 Oct 2009 12:50:34 -0400, Andrei Alexandrescu > > > wrote: > > > > > > > > What does iota mean? > > > > > > > > http://www.digitalmars.com/d/2.0/phobos/std_range.html#iota > > > > > > > > Irony minded. I'm destroyed. > > > > > > Hm... this is slightly off topic, but that function signature is > > > absolutely horrendous (in fact, I thought you linked to the wrong place at > > > first). Isn't there any way to avoid putting half the type construction > > > as the return value? Do all range-creating functions suffer from this > > > problem? Maybe it's just a ddoc problem. > > > > I wanted to use auto, but ddoc cannot document functions with auto returns. > > Is it too hard to fix that? I think ddoc works before the semantic pass so the > return type is null by then, but it isn't very hard to see a "if type.next != > null" in the source code... > > I say it because I also find horrendous the signature. And what's more, it's > hard to find the word "iota" there. > > I also think "iota" is an awful name for that function. It'd be really sweet if someone stepped up to work on ddoc with the same gusto that Don has been on other parts of DMD. IMHO, without having done enough code study, ddoc should be split off into a separate executable that shared the first stages of DMD. I'm not sure that'd help it act different where it needs to act different, but it'd certainly be an interesting exercise to get more data about how re-usable parts of DMD are. Alternatively, it'd also be interesting to explore making it _really_ separate and use the new -X output and build docs completely off that. Later, Brad
Re: OT: Hats... Mostly unnecessary?
It had a button.
Re: [OT] Re: Targeting C
Andrei Alexandrescu wrote: Steven Schveighoffer wrote: On Fri, 23 Oct 2009 12:50:34 -0400, Andrei Alexandrescu wrote: What does iota mean? http://www.digitalmars.com/d/2.0/phobos/std_range.html#iota Irony minded. I'm destroyed. Hm... this is slightly off topic, but that function signature is absolutely horrendous (in fact, I thought you linked to the wrong place at first). Isn't there any way to avoid putting half the type construction as the return value? Do all range-creating functions suffer from this problem? Maybe it's just a ddoc problem. I wanted to use auto, but ddoc cannot document functions with auto returns. Is it too hard to fix that? I think ddoc works before the semantic pass so the return type is null by then, but it isn't very hard to see a "if type.next != null" in the source code... I say it because I also find horrendous the signature. And what's more, it's hard to find the word "iota" there. I also think "iota" is an awful name for that function.
Re: IDE for D? Recommendations?
AJ Wrote: > Anyone have recommendations for which IDE to use to do an evaluation of D > with? I don't need powerful capabilities as I'm just looking to write some > code and get a feel for some things in D. A bundle would be great. Also, I > think it would be fun to look at the libraries during the eval. "Eval" is > too strong... I just wanna play around with D a little bit in my spare time. > If I can't be up an running in less than an hour, including any reading > necessary to get set up, I'll have to save it for another time. I definitely > don't want to be at a commandline prompt. All > comments/recommendations/opinions welcomed. (Thanks in advance). > > Don't what to imply this isn't a reasonable question as this page doesn't exactly answer you question: http://www.prowiki.org/wiki4d/wiki.cgi?EditorSupport
Re: Illegal instruction in GetOpenFileName()
Jeremie Pelletier wrote: I get an illegal instruction exception when using GetOpenFileName(), I know its strange to post windows issues here, but the bug is only when using either DMD or DMC. VC++ 2008 produces a working executable in both 32bits and 64bits. I'd compare the asm generated by VC++ with DMC++.
Re: Semicolons: mostly unnecessary?
Walter Bright wrote: Max Samukha wrote: On Thu, 22 Oct 2009 23:21:25 +0200, bambo wrote: Walter Bright schrieb: Adam D. Ruppe wrote: mostcertainly doesNOTmeanalanguageisnecessarilyeasiertoparseSymbolsgiveus aparsinganchorperiodsinasentencearentstrictlynecessarywecould putoneperlineorjustfigureoutwheretheybelongbyparsingthecontext Butthatsfairlyobviouslymuchharderthanusingperiodstofollowwhere youareSemicolonsarethesamething (Fixed that for you!) Walter, what a remarkable proove the semicolon helps us all a lot! You are so BRIGHT! You are so creative and intelligent! I LOVE YOU! This is one of Walter's proofs that don't prove anything. Spaces between words are *not redundant*. Armed with a dictionary, there's really only one parse of the above text that works. therapistswhopreachedonweeknights Andrei
Re: Semicolons: mostly unnecessary?
Walter Bright: > Armed with a dictionary, there's really only one parse of the above text > that works. http://en.wikipedia.org/wiki/Viterbi_algorithm Bye, bearophile
Re: Semicolons: mostly unnecessary?
On Fri, Oct 23, 2009 at 04:07:42PM -0400, Nick Sabalausky wrote: > There's only one possible way: > > Ift hep oint is NT, pla I nob VI O' U.S. Fromt he, a bovef. Ew! Ers y m > bols! > > It's obviously a note from a crazy person. Or is it a UNIX command line? :P -- Adam D. Ruppe http://arsdnet.net
Re: Semicolons: mostly unnecessary?
"Walter Bright" wrote in message news:hbt1sv$165...@digitalmars.com... > Max Samukha wrote: >> On Thu, 22 Oct 2009 23:21:25 +0200, bambo wrote: >> >>> Walter Bright schrieb: Adam D. Ruppe wrote: mostcertainly doesNOTmeanalanguageisnecessarilyeasiertoparseSymbolsgiveus aparsinganchorperiodsinasentencearentstrictlynecessarywecould putoneperlineorjustfigureoutwheretheybelongbyparsingthecontext Butthatsfairlyobviouslymuchharderthanusingperiodstofollowwhere youareSemicolonsarethesamething (Fixed that for you!) >>> Walter, what a remarkable proove the semicolon helps us all a lot! >>> You are so BRIGHT! You are so creative and intelligent! >>> >>> I LOVE YOU! >> >> This is one of Walter's proofs that don't prove anything. Spaces >> between words are *not redundant*. > > Armed with a dictionary, there's really only one parse of the above text > that works. Consider also that when text is encrypted using pre-computer > methods, the first thing done is all spaces are removed and it is put in > monocase (because that makes it harder for cryptanalysis). Human > decryptors put them back in. > > Consider the fragment: > > Ifthepointisntplainobviousfromtheabovefewersymbols > > Where else could the spaces possibly go? There's only one possible way: Ift hep oint is NT, pla I nob VI O' U.S. Fromt he, a bovef. Ew! Ers y m bols! It's obviously a note from a crazy person.
Re: Semicolons: mostly unnecessary?
Walter Bright wrote: Max Samukha wrote: On Thu, 22 Oct 2009 23:21:25 +0200, bambo wrote: Walter Bright schrieb: Adam D. Ruppe wrote: mostcertainly doesNOTmeanalanguageisnecessarilyeasiertoparseSymbolsgiveus aparsinganchorperiodsinasentencearentstrictlynecessarywecould putoneperlineorjustfigureoutwheretheybelongbyparsingthecontext Butthatsfairlyobviouslymuchharderthanusingperiodstofollowwhere youareSemicolonsarethesamething (Fixed that for you!) Walter, what a remarkable proove the semicolon helps us all a lot! You are so BRIGHT! You are so creative and intelligent! I LOVE YOU! This is one of Walter's proofs that don't prove anything. Spaces between words are *not redundant*. Armed with a dictionary, there's really only one parse of the above text that works. Consider also that when text is encrypted using pre-computer methods, the first thing done is all spaces are removed and it is put in monocase (because that makes it harder for cryptanalysis). Human decryptors put them back in. Consider the fragment: Ift hepo inti sn tplainobviousfromthe abovefewersymbols SYNTAX ERROR!
Re: Semicolons: mostly unnecessary?
Max Samukha wrote: On Thu, 22 Oct 2009 23:21:25 +0200, bambo wrote: Walter Bright schrieb: Adam D. Ruppe wrote: mostcertainly doesNOTmeanalanguageisnecessarilyeasiertoparseSymbolsgiveus aparsinganchorperiodsinasentencearentstrictlynecessarywecould putoneperlineorjustfigureoutwheretheybelongbyparsingthecontext Butthatsfairlyobviouslymuchharderthanusingperiodstofollowwhere youareSemicolonsarethesamething (Fixed that for you!) Walter, what a remarkable proove the semicolon helps us all a lot! You are so BRIGHT! You are so creative and intelligent! I LOVE YOU! This is one of Walter's proofs that don't prove anything. Spaces between words are *not redundant*. Armed with a dictionary, there's really only one parse of the above text that works. Consider also that when text is encrypted using pre-computer methods, the first thing done is all spaces are removed and it is put in monocase (because that makes it harder for cryptanalysis). Human decryptors put them back in. Consider the fragment: Ifthepointisntplainobviousfromtheabovefewersymbols Where else could the spaces possibly go?
Re: No header files?
On Fri, 23 Oct 2009 15:50:18 -0400, Walter Bright wrote: Yigal Chripun wrote: Shared libraries are inherently not portable from system to system. only if you consider dlls and so. Java jars are portable. so do .net assemblies. Jars and .nets are not executable code. Dlls and shared libraries are. .net assemblies built by visual studio are packaged as dlls. Although I don't know exactly how they are executed, I'm sure it's some sort of bytecode. Just saying... -Steve
Re: No header files?
Yigal Chripun wrote: Shared libraries are inherently not portable from system to system. only if you consider dlls and so. Java jars are portable. so do .net assemblies. Jars and .nets are not executable code. Dlls and shared libraries are.
Re: Targeting C
Andrei Alexandrescu, el 23 de octubre a las 13:06 me escribiste: > Pelle Månsson wrote: > >bearophile wrote: > >>Yigal Chripun: > >> > >>>Hell no. This is why I hate certain programming languages. > >>>if you are trying to obfuscate the language than why not just define: > >>>rtqfrdsg and fdkjtkf as the function names? > >> > >>Don't be silly. In my dlibs "xsomething" are the lazy functions, > >>and "something" are the strict ones. That's not obfuscated, you > >>need seconds to learn a single easy rule. > >> > >>Bye, > >>bearophile > >I think the complaint was not as much about the x as the iota. > >Seriously, iota? > > > >However, I like the array(range(0,10)) where range is always lazy, > >and array forces eagerness, better than separate xrange and range > >functions. > > Orthogonality for the win. Sometimes "practicality beats purity" :) But I don't really care that much about this one... -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- DIEZ "PUNGAS" MENOS -- Crónica TV
Re: Targeting C
Leandro Lucarella wrote: Andrei Alexandrescu, el 23 de octubre a las 11:09 me escribiste: Bill Baxter wrote: On Fri, Oct 23, 2009 at 5:13 AM, Andrei Alexandrescu wrote: Yigal Chripun wrote: On 23/10/2009 13:02, bearophile wrote: Chris Nicholson-Sauls: I prefer this (Scala): list = list ++ (0 to 10) That's quite less readable. Scala sometimes has some unreadable syntax. Python has taught me how much useful a readable syntax is :-) Designing languages requires to find a balance between several different and opposed needs. Bye, bearophile how about this hypothetical syntax: list ~= [0..10]; I'm not sure what the type of "list" is supposed to be, but this works today for arrays: list ~= array(iota(0, 10)); While we're not on the subject "Iota" is right up there with "inSitu". I know it has a precedent elsewhere, but it sounds about as user friendly as monads. It just sounds like the language it trying to be snooty. Like "if you don't even know what iota is, you're clearly not qualified to join our little D club. Maybe you should try Java... or Logo". Compare that to Python where it's called "range", something every Joe the Programmer can certainly grok without having to get a Greek to English dictionary. Given that "range" is already taken, what name do you think would work best? (I sometimes deliberately prefer less-used names because the more used ones often come with baggage and ambiguities (as is the case with "range"). Case in point, "in-situ" is more informative than "in-place" because the former suggests emplacement of a substructure within a larger structure. So to me an "in-situ" class member inside a class has a clear meaning that the member sits right there within the class. But anyhow I will use in-place from now on.) I don't see "range" taken inside the range module. I think it even makes sense, iota() is the more primitive range ever, so why don't just call it range()? :) This was my thought as well. I don't know if it fares well in the ambiguity department, though.
Re: Targeting C
Andrei Alexandrescu, el 23 de octubre a las 11:09 me escribiste: > Bill Baxter wrote: > >On Fri, Oct 23, 2009 at 5:13 AM, Andrei Alexandrescu > > wrote: > >>Yigal Chripun wrote: > >>>On 23/10/2009 13:02, bearophile wrote: > Chris Nicholson-Sauls: > > >I prefer this (Scala): > >list = list ++ (0 to 10) > That's quite less readable. Scala sometimes has some unreadable syntax. > Python has taught me how much useful a readable syntax is :-) > Designing languages requires to find a balance between several different > and opposed needs. > > Bye, > bearophile > >>>how about this hypothetical syntax: > >>> > >>>list ~= [0..10]; > >>I'm not sure what the type of "list" is supposed to be, but this works today > >>for arrays: > >> > >>list ~= array(iota(0, 10)); > > > >While we're not on the subject > >"Iota" is right up there with "inSitu". > >I know it has a precedent elsewhere, but it sounds about as user > >friendly as monads. It just sounds like the language it trying to be > >snooty. Like "if you don't even know what iota is, you're clearly not > >qualified to join our little D club. Maybe you should try Java... or > >Logo". Compare that to Python where it's called "range", something > >every Joe the Programmer can certainly grok without having to get a > >Greek to English dictionary. > > Given that "range" is already taken, what name do you think would work best? > > (I sometimes deliberately prefer less-used names because the more > used ones often come with baggage and ambiguities (as is the case > with "range"). Case in point, "in-situ" is more informative than > "in-place" because the former suggests emplacement of a substructure > within a larger structure. So to me an "in-situ" class member inside > a class has a clear meaning that the member sits right there within > the class. But anyhow I will use in-place from now on.) I don't see "range" taken inside the range module. I think it even makes sense, iota() is the more primitive range ever, so why don't just call it range()? :) Anyway, I think it makes perfect sense to have the compiler translating x..y to a iota/range(x, y). -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- CAROZO CON FARINGITIS -- Crónica TV
Re: IDE for D? Recommendations?
AJ Wrote: > Anyone have recommendations for which IDE to use to do an evaluation of D > with? I don't need powerful capabilities as I'm just looking to write some > code and get a feel for some things in D. A bundle would be great. Also, I > think it would be fun to look at the libraries during the eval. "Eval" is > too strong... I just wanna play around with D a little bit in my spare time. > If I can't be up an running in less than an hour, including any reading > necessary to get set up, I'll have to save it for another time. I definitely > don't want to be at a commandline prompt. All > comments/recommendations/opinions welcomed. (Thanks in advance). Try my D-IDE alexanderbothe.com/?id=27
Re: Targeting C
Pelle Månsson wrote: Andrei Alexandrescu wrote: Yigal Chripun wrote: On 23/10/2009 13:02, bearophile wrote: Chris Nicholson-Sauls: I prefer this (Scala): list = list ++ (0 to 10) That's quite less readable. Scala sometimes has some unreadable syntax. Python has taught me how much useful a readable syntax is :-) Designing languages requires to find a balance between several different and opposed needs. Bye, bearophile how about this hypothetical syntax: list ~= [0..10]; I'm not sure what the type of "list" is supposed to be, but this works today for arrays: list ~= array(iota(0, 10)); Andrei What does iota mean? In English: "A very small amount". This helped didn't it? ;) The others have already answered for the D meaning. Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: No header files?
"Walter Bright" wrote in message news:hbr6fu$8d...@digitalmars.com... > Denis Koroskin wrote: >> On Fri, 23 Oct 2009 05:20:04 +0400, Nick Sabalausky wrote: >> >>> "Denis Koroskin" <2kor...@gmail.com> wrote in message >>> news:op.u17vung8o7c...@korden-pc... On Thu, 22 Oct 2009 23:42:06 +0400, AJ wrote: > > ""Jérôme M. Berger"" wrote in message > news:hbq76m$18i...@digitalmars.com... > > All your posts are showing up empty here Jerome. > Nope, they are perfectly fine. Try configuring your Thunderbird/Mnenhy or use alternative NNTP client. >>> >>> They show up as attachments for me. >>> >>> >> >> Looks like Outlook Express is crappy too :) >> >> Try Opera > > I'm using thunderbird, and things work fine. I tried thunderbird a couple times but with both the GTK-ness of it and the Mozilla-ness (can't change the things I want to change without clumbsy manual hacking up of obscure config files) drove me far, far away. There's some things I would definitely like to change about OE, but for the most part I've been pretty happy with it, and the downsides (like, one or two people with their messages as attachments) haven't been big enough of a deal for me to add yet another GTK and/or Mozilla app to my system (I'm already fed up enough with FF, GAIM (yea, I'm still calling it GAIM, mainly as a big FU to AOL), GIMP, and Inkscape, but I can't replace those because as mush as I dislike them, I've yet to find (or find the time to make) anything better).
Re: Targeting C
Yigal Chripun wrote: On 23/10/2009 18:29, bearophile wrote: Yigal Chripun: Ranges are already part of the compiler because of foreach, can we also add language support for Range literals? In both iota and other possible implementations I'd like the arguments used by Python range/xrange, they are optimal, and better than the currently ones used by iota. And being ranges lazy and eager (strict) so common, I may want both versions, so I don't need array(iota(...)) (all this is present in my dlibs). What about xiota for the lazy version? Or maybe aiota for the eager version? :-) Bye, bearophile Hell no. This is why I hate certain programming languages. if you are trying to obfuscate the language than why not just define: rtqfrdsg and fdkjtkf as the function names? names are important and they must be readable (in English. latin/greek/hindu/klingon/etc are not accepted). I don't care if I need to type ten letters instead of just five if later on I can understand immediately what the code does instead of spending half an hour reading the (outdated) documentation if I even bothered to write one. Note that both "iota" and "in situ" are in the "Collins Cobuild English Language Dictionary". Here are their definitions: "in situ" is used to describe something that remains in its original or appropriate place while work is done on it. "iota" An iota of something is an extremely small amount of it. Therefore, both should be considered acceptable English words. However whereas "inSitu" says exactly what it means, I'm not so sure about "iota" Jerome PS: For those who don't know, the Collins Cobuild is special in that it is built using statistics on word usage. They choose which words to include based on how frequently those words are used in common English. -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: Targeting C
On 23/10/2009 19:49, Pelle Månsson wrote: bearophile wrote: Yigal Chripun: Hell no. This is why I hate certain programming languages. if you are trying to obfuscate the language than why not just define: rtqfrdsg and fdkjtkf as the function names? Don't be silly. In my dlibs "xsomething" are the lazy functions, and "something" are the strict ones. That's not obfuscated, you need seconds to learn a single easy rule. Bye, bearophile I think the complaint was not as much about the x as the iota. Seriously, iota? However, I like the array(range(0,10)) where range is always lazy, and array forces eagerness, better than separate xrange and range functions. first thing xsomthing *is* silly and I agree with andrei and pelle about having an array function that forces eagerness. but more generally speaking, each individual part can be rationalized like xsomething is lazy, iota generates a lazy range, etc.. but combined you get meaningless letters.. xaiota? rule 1 of programming - code is read 1000 times more then written. today at the age of terabyte HDDs writing strcmp instead of string_compare or stringCompare (depends on your love for camels) is absolutely ridiculous.
Re: IDE for D? Recommendations?
"AJ" wrote in message news:hbr637$7f...@digitalmars.com... > Anyone have recommendations for which IDE to use to do an evaluation of D > with? I don't need powerful capabilities as I'm just looking to write some > code and get a feel for some things in D. A bundle would be great. Also, I > think it would be fun to look at the libraries during the eval. "Eval" is > too strong... I just wanna play around with D a little bit in my spare > time. If I can't be up an running in less than an hour, including any > reading necessary to get set up, I'll have to save it for another time. I > definitely don't want to be at a commandline prompt. All > comments/recommendations/opinions welcomed. (Thanks in advance). I use Programmer's Notepad 2. Very responsive, low memory footprint and cpu usage, built-in D syntax highlighting.
Re: No header files?
Walter Bright wrote: Denis Koroskin wrote: On Fri, 23 Oct 2009 05:20:04 +0400, Nick Sabalausky wrote: "Denis Koroskin" <2kor...@gmail.com> wrote in message news:op.u17vung8o7c...@korden-pc... On Thu, 22 Oct 2009 23:42:06 +0400, AJ wrote: ""Jérôme M. Berger"" wrote in message news:hbq76m$18i...@digitalmars.com... All your posts are showing up empty here Jerome. Nope, they are perfectly fine. Try configuring your Thunderbird/Mnenhy or use alternative NNTP client. They show up as attachments for me. Looks like Outlook Express is crappy too :) Try Opera I'm using thunderbird, and things work fine. That's lucky since I'm using Thunderbird too ;) And yes, OE is a piece of crap that doesn't respect standards. I sometimes have problems with messages posted by OE users too... Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: Targeting C
Pelle Månsson wrote: bearophile wrote: Yigal Chripun: Hell no. This is why I hate certain programming languages. if you are trying to obfuscate the language than why not just define: rtqfrdsg and fdkjtkf as the function names? Don't be silly. In my dlibs "xsomething" are the lazy functions, and "something" are the strict ones. That's not obfuscated, you need seconds to learn a single easy rule. Bye, bearophile I think the complaint was not as much about the x as the iota. Seriously, iota? However, I like the array(range(0,10)) where range is always lazy, and array forces eagerness, better than separate xrange and range functions. Orthogonality for the win. Andrei
Re: Targeting C
Bill Baxter wrote: On Fri, Oct 23, 2009 at 5:13 AM, Andrei Alexandrescu wrote: Yigal Chripun wrote: On 23/10/2009 13:02, bearophile wrote: Chris Nicholson-Sauls: I prefer this (Scala): list = list ++ (0 to 10) That's quite less readable. Scala sometimes has some unreadable syntax. Python has taught me how much useful a readable syntax is :-) Designing languages requires to find a balance between several different and opposed needs. Bye, bearophile how about this hypothetical syntax: list ~= [0..10]; I'm not sure what the type of "list" is supposed to be, but this works today for arrays: list ~= array(iota(0, 10)); While we're not on the subject "Iota" is right up there with "inSitu". I know it has a precedent elsewhere, but it sounds about as user friendly as monads. It just sounds like the language it trying to be snooty. Like "if you don't even know what iota is, you're clearly not qualified to join our little D club. Maybe you should try Java... or Logo". Compare that to Python where it's called "range", something every Joe the Programmer can certainly grok without having to get a Greek to English dictionary. Given that "range" is already taken, what name do you think would work best? (I sometimes deliberately prefer less-used names because the more used ones often come with baggage and ambiguities (as is the case with "range"). Case in point, "in-situ" is more informative than "in-place" because the former suggests emplacement of a substructure within a larger structure. So to me an "in-situ" class member inside a class has a clear meaning that the member sits right there within the class. But anyhow I will use in-place from now on.) Andrei
Re: [OT] Re: Targeting C
Steven Schveighoffer wrote: On Fri, 23 Oct 2009 12:50:34 -0400, Andrei Alexandrescu wrote: What does iota mean? http://www.digitalmars.com/d/2.0/phobos/std_range.html#iota Irony minded. I'm destroyed. Hm... this is slightly off topic, but that function signature is absolutely horrendous (in fact, I thought you linked to the wrong place at first). Isn't there any way to avoid putting half the type construction as the return value? Do all range-creating functions suffer from this problem? Maybe it's just a ddoc problem. I wanted to use auto, but ddoc cannot document functions with auto returns. Andrei P.S. It looks like TDPL will scream today through the 100,000 words barrier (at 97,781 words now, see and track at www.erdani.com). When that happens, I'll celebrate by making another excerpt available online.
Re: [OT] What should be in a programming language?
Yigal Chripun Wrote:
> On 23/10/2009 14:42, Jason House wrote:
> > I've been thinking lately about what my ideal programming language
> > would look like and what I might write if I tried to create one.
> > Below is a short list of big things I'd do. What do you think of my
> > ideas? What would you do?
> >
> > I'd look to D and Scala for inspiration, but want to allow better
> > reasoning about code.
> >
> > I'd use D's transitive const and use transitive pure instead of
> > transitive immutable.
> >
> > Functions can't effect glabal variables unless marked as such. I'll
> > have to learn what a monad is so that some side effects can be
> > hidden?
> >
> > By default, a function can not keep its variables past function
> > scope. If a parameter or local variable is to remain for longer it
> > must be marked as such in its type.
> >
> > Similarly, all function arguments will default to (transitive) const.
> > Any mutable arguments must be marked as such. I'm unsure if ref
> > arguments should come in a final and non-final form. One nice side
> > effect of this is that value types vs. reference types don't require
> > special consideration.
> >
> > I'd probably do away with out arguments in favor of return tuples.
> >
> > All types are not nullable by default. T and T? seem reasonable
> > enough. I'd probably twist that a bit and use a beefed up variable
> > declaration similar to scala. "pure? x: T = ..." would be a nullable
> > immutable variable of type T.
> >
> > Compile time capabilities would exceed D's. I'm thinking of a simple
> > marker to make anything compile time (i.e. #). #if would be like
> > static if. #pure would be a manifest constant. An array with some
> > compile time values would be easy [foo(7), #bar(8)]. This also means
> > #switch and #foreach would exist (among other things). Generics with
> > compile time arguments become templates.
> >
> > I would have a type type, usable for both compile time and run time
> > reflection.
> >
> > I've probably forgotten a number of basic things, but that should be
> > enough for now.
>
> my list would be similar:
> non-nullable references by default, concurrency semantics (I liked
> Bartosz' design),
That's an important one that I forgot to list: an ownership scheme similar to
Bartosz's (I'd favor a slight reduction in annotation, but the same basic thing)
> transitive const and everything is const by default,
> immutable as part of the concurrency ownership design,
> functions would be defined as in ML: they take one tuple argument and
> return one tuple argument
I like scala's concept of multiple input tuples, and the freedom to use () or
{} when specifying a tuple. I might be slightly stricter with how each tuple is
used such that the library writer says which form is allowed. This has the
awesome side effects of making libraries look like part of the language.
>
> i don't like the #if, etc idea and would prefer a proper AST macro
> system with proper hygiene
The AST macro stuff predates my participation on this list. Have any good links
explaining how it works? I've been thinking of allowing expressions, statements
(and friends) as object types and then allowing mixing in of those objects...
#var declareX = Statement ("int x=3");
#mixin declareX;
... or something along those lines...
>
> I'd remove static from the language completely and instead would have
> metaclasses.
I agree with no statics. What are metaclasses? I like how scala defines
singletons for statics (object in scala type declaration)
> other OOP changes - better separation between sub-typing and sub-classing:
>
> type interfaceA extends interfaceB, interfaceC {}
> implementation implA extends implB, implC implements interfaceA,
> interfaceD{}
>
> auto obj = interfaceA.new(); // returns an implementation, e.g. implA
>
> ionstead of the classic:
> class A {}
> class B: A {}
>
> we'll have:
> type A {}
> type B extends A {}
> implementation A implements A{}
> implementation B extends implementation A implements B {}
There seems to be redundency here. Why would you/others want that? Super
verbose code makes it tough to attract users.
> everything is an object and no special treatment for specific types
I don't think "everything is an object" works under the hood, but I do like
making that transparent. A lot of the items allow transparent use of reference
and value types (scope by default unless explicitly marked/allocated, and
transitive const by default unless passed by ref)
Re: Targeting C
bearophile wrote: Yigal Chripun: Hell no. This is why I hate certain programming languages. if you are trying to obfuscate the language than why not just define: rtqfrdsg and fdkjtkf as the function names? Don't be silly. In my dlibs "xsomething" are the lazy functions, and "something" are the strict ones. That's not obfuscated, you need seconds to learn a single easy rule. Bye, bearophile I think the complaint was not as much about the x as the iota. Seriously, iota? However, I like the array(range(0,10)) where range is always lazy, and array forces eagerness, better than separate xrange and range functions.
[OT] Re: Targeting C
On Fri, 23 Oct 2009 12:50:34 -0400, Andrei Alexandrescu wrote: What does iota mean? http://www.digitalmars.com/d/2.0/phobos/std_range.html#iota Irony minded. I'm destroyed. Hm... this is slightly off topic, but that function signature is absolutely horrendous (in fact, I thought you linked to the wrong place at first). Isn't there any way to avoid putting half the type construction as the return value? Do all range-creating functions suffer from this problem? Maybe it's just a ddoc problem. -Steve
Re: Targeting C
Yigal Chripun: > Hell no. This is why I hate certain programming languages. > if you are trying to obfuscate the language than why not just define: > rtqfrdsg and fdkjtkf as the function names? Don't be silly. In my dlibs "xsomething" are the lazy functions, and "something" are the strict ones. That's not obfuscated, you need seconds to learn a single easy rule. Bye, bearophile
Re: Semicolons: mostly unnecessary?
Yigal Chripun: > The trade-off here is obvious: if you use line continuations like in > python they would be very rare but would not be automatic and consistent > when you do need to use them. In my Python code (or in good code you may find around, like in some modules of the std library) you may have a hard time finding few line continuations. Generally you can avoid them putting code in parentheses. And if/when you want to use them it's simple. So I think you are wrong. Bye, bearophile
Re: Targeting C
On 23/10/2009 18:29, bearophile wrote: Yigal Chripun: Ranges are already part of the compiler because of foreach, can we also add language support for Range literals? In both iota and other possible implementations I'd like the arguments used by Python range/xrange, they are optimal, and better than the currently ones used by iota. And being ranges lazy and eager (strict) so common, I may want both versions, so I don't need array(iota(...)) (all this is present in my dlibs). What about xiota for the lazy version? Or maybe aiota for the eager version? :-) Bye, bearophile Hell no. This is why I hate certain programming languages. if you are trying to obfuscate the language than why not just define: rtqfrdsg and fdkjtkf as the function names? names are important and they must be readable (in English. latin/greek/hindu/klingon/etc are not accepted). I don't care if I need to type ten letters instead of just five if later on I can understand immediately what the code does instead of spending half an hour reading the (outdated) documentation if I even bothered to write one.
Re: Targeting C
Bill Baxter, el 23 de octubre a las 08:51 me escribiste: > > list ~= array(iota(0, 10)); > > While we're not on the subject > "Iota" is right up there with "inSitu". > I know it has a precedent elsewhere, but it sounds about as user > friendly as monads. It just sounds like the language it trying to be > snooty. Like "if you don't even know what iota is, you're clearly not > qualified to join our little D club. Maybe you should try Java... or > Logo". Compare that to Python where it's called "range", something > every Joe the Programmer can certainly grok without having to get a > Greek to English dictionary. Thanks for mention this, now I don't feel *that* idiotic to have to go and search what iota means every time I see it =) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Did you know the originally a Danish guy invented the burglar-alarm unfortunately, it got stolen
Re: Semicolons: mostly unnecessary?
On 22/10/2009 12:58, bearophile wrote: Nick Sabalausky: I'm already kicking myself for trying to jump into the middle of yet another semicolon debate, but..."burden" of semicolons? Isn't that a bit overstated? I suppose it depends on the person, but I find it to be every bit as automatic as reaching for the Shift key when I write camelcase, or hitting enter for a new line, or going for control when I want to arrow around a word-at-a-time. And those are hardly burdens (and sure, technically a semicolon plus newline is more than *just* newline, but only negligibly so). Yes, you are right, adding the semicolon doesn't take a lot of time, but when you miss it, the program doesn't compile, and you have to find where you have missed it, sometimes this requires some time. And I've seen plenty of newbie programmers that think "the computer" is idiot and fussy for asking them to put such useless semicolons. I guess this is not a strong argument because newbie programmers will probably not want to start with D as first language :-) Bye, bearophile Let's bring another language into the mix: Pascal uses periods as the statement separator but it's only required between two statements. something like begin statementA. statementB. statementC end notice how there's no period after statementC. This was considered at the time as confusing and people preferred c style semicolons because they are consistently everywhere so you don't need to think "do I need to put it here or not" The trade-off here is obvious: if you use line continuations like in python they would be very rare but would not be automatic and consistent when you do need to use them. I personally prefer to have semicolons.
Re: Targeting C
Pelle Månsson wrote: Andrei Alexandrescu wrote: Yigal Chripun wrote: On 23/10/2009 13:02, bearophile wrote: Chris Nicholson-Sauls: I prefer this (Scala): list = list ++ (0 to 10) That's quite less readable. Scala sometimes has some unreadable syntax. Python has taught me how much useful a readable syntax is :-) Designing languages requires to find a balance between several different and opposed needs. Bye, bearophile how about this hypothetical syntax: list ~= [0..10]; I'm not sure what the type of "list" is supposed to be, but this works today for arrays: list ~= array(iota(0, 10)); Andrei What does iota mean? http://www.digitalmars.com/d/2.0/phobos/std_range.html#iota Irony minded. I'm destroyed. Andrei
Re: Targeting C
On Fri, 23 Oct 2009 18:16:29 +0200, Pelle M?nsson wrote: >Andrei Alexandrescu wrote: >> Yigal Chripun wrote: >>> On 23/10/2009 13:02, bearophile wrote: Chris Nicholson-Sauls: > I prefer this (Scala): > list = list ++ (0 to 10) That's quite less readable. Scala sometimes has some unreadable syntax. Python has taught me how much useful a readable syntax is :-) Designing languages requires to find a balance between several different and opposed needs. Bye, bearophile >>> >>> how about this hypothetical syntax: >>> >>> list ~= [0..10]; >> >> I'm not sure what the type of "list" is supposed to be, but this works >> today for arrays: >> >> list ~= array(iota(0, 10)); >> >> >> Andrei >What does iota mean? A sequence of integral numbers. I guess the name comes from APL.
Re: Targeting C
Yigal Chripun: > Ranges are already part of the compiler because of foreach, can we also > add language support for Range literals? In both iota and other possible implementations I'd like the arguments used by Python range/xrange, they are optimal, and better than the currently ones used by iota. And being ranges lazy and eager (strict) so common, I may want both versions, so I don't need array(iota(...)) (all this is present in my dlibs). What about xiota for the lazy version? Or maybe aiota for the eager version? :-) Bye, bearophile
Re: IDE for D? Recommendations?
I don't know about the D support, but codeblocks is not really outdated. If you get the "nightly" builds the last version is from October 10 2009. They are usually very stable (full with bug fixes and new features), by now I would say even more than the version in the main page. "Anders F Björklund" escreveu na mensagem news:hbrk0p$11m...@digitalmars.com... AJ wrote: Anyone have recommendations for which IDE to use to do an evaluation of D with? I don't need powerful capabilities as I'm just looking to write some code and get a feel for some things in D. A bundle would be great. Also, I think it would be fun to look at the libraries during the eval. "Eval" is too strong... I just wanna play around with D a little bit in my spare time. If I can't be up an running in less than an hour, including any reading necessary to get set up, I'll have to save it for another time. I definitely don't want to be at a commandline prompt. All comments/recommendations/opinions welcomed. (Thanks in advance). You can use Code::Blocks and wxWidgets for an IDE and a GUI on all platforms (Windows, GNU/Linux, Mac OS X and FreeBSD) It's outdated (2008) and not a native D environment (C++), so it probably won't work for evaluating D2 or TDPL book. But it should be up and running is much less than an hour, and it's also available in the package/ports repositories. You can use either DMD/GDC and Phobos/Tango as you choose, and the program and libraries are Free Software (GPL/LGPL). http://wxd.sourceforge.net/#codeblocks http://gdcwin.sourceforge.net/ (MinGW) --anders
Re: [OT] What should be in a programming language?
Jason House: > Denis Koroskin: > > I believe templates are better be written in imperative style. That's why > > a built-in "type" type is needed. > > Absolutely! Do you have any inspirational examples? I have found two my old posts where I have discussed a little about this: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=91015 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=91017 Hope that helps. I'd like to have a type type in D :-) I think it can't replace all current usages of templates, but replaces some of those usages with something simpler to use. Bye, bearophile
Re: Targeting C
On 23/10/2009 17:51, Bill Baxter wrote:
On Fri, Oct 23, 2009 at 5:13 AM, Andrei Alexandrescu
wrote:
Yigal Chripun wrote:
On 23/10/2009 13:02, bearophile wrote:
Chris Nicholson-Sauls:
I prefer this (Scala):
list = list ++ (0 to 10)
That's quite less readable. Scala sometimes has some unreadable syntax.
Python has taught me how much useful a readable syntax is :-)
Designing languages requires to find a balance between several different
and opposed needs.
Bye,
bearophile
how about this hypothetical syntax:
list ~= [0..10];
I'm not sure what the type of "list" is supposed to be, but this works today
for arrays:
list ~= array(iota(0, 10));
While we're not on the subject
"Iota" is right up there with "inSitu".
I know it has a precedent elsewhere, but it sounds about as user
friendly as monads. It just sounds like the language it trying to be
snooty. Like "if you don't even know what iota is, you're clearly not
qualified to join our little D club. Maybe you should try Java... or
Logo". Compare that to Python where it's called "range", something
every Joe the Programmer can certainly grok without having to get a
Greek to English dictionary.
--bb
Ranges are already part of the compiler because of foreach, can we also
add language support for Range literals?
i.e
(1..10) => range(1, 10) //(I'm using BB's much better name)
[1..10] => array(range(1, 10))
it already is supported is foreach, isn't it?
foreach (i; 1..10) {...}
Re: Targeting C
Andrei Alexandrescu wrote: Yigal Chripun wrote: On 23/10/2009 13:02, bearophile wrote: Chris Nicholson-Sauls: I prefer this (Scala): list = list ++ (0 to 10) That's quite less readable. Scala sometimes has some unreadable syntax. Python has taught me how much useful a readable syntax is :-) Designing languages requires to find a balance between several different and opposed needs. Bye, bearophile how about this hypothetical syntax: list ~= [0..10]; I'm not sure what the type of "list" is supposed to be, but this works today for arrays: list ~= array(iota(0, 10)); Andrei What does iota mean?
Re: Targeting C
On Fri, Oct 23, 2009 at 5:13 AM, Andrei Alexandrescu wrote: > Yigal Chripun wrote: >> >> On 23/10/2009 13:02, bearophile wrote: >>> >>> Chris Nicholson-Sauls: >>> I prefer this (Scala): list = list ++ (0 to 10) >>> >>> That's quite less readable. Scala sometimes has some unreadable syntax. >>> Python has taught me how much useful a readable syntax is :-) >>> Designing languages requires to find a balance between several different >>> and opposed needs. >>> >>> Bye, >>> bearophile >> >> how about this hypothetical syntax: >> >> list ~= [0..10]; > > I'm not sure what the type of "list" is supposed to be, but this works today > for arrays: > > list ~= array(iota(0, 10)); While we're not on the subject "Iota" is right up there with "inSitu". I know it has a precedent elsewhere, but it sounds about as user friendly as monads. It just sounds like the language it trying to be snooty. Like "if you don't even know what iota is, you're clearly not qualified to join our little D club. Maybe you should try Java... or Logo". Compare that to Python where it's called "range", something every Joe the Programmer can certainly grok without having to get a Greek to English dictionary. --bb
Re: this() not executing code on structs
Denis Koroskin wrote:
On Fri, 23 Oct 2009 18:46:47 +0400, Andrei Alexandrescu
wrote:
Don wrote:
Bartosz Milewski wrote:
Andrei Alexandrescu Wrote:
this() { myCount = count++; } // ERROR
It's worse than that. Try this:
struct foo {
this(int dummy = 0) { writeln("Default constructor");}
}
foo x = foo();
Nothing gets printed. If default constructors are disallowed, so
should constructors with all parameters defaulted.
Ouch.
It's because it's interpreting foo() as a struct literal.
If a struct has any constructors, struct literals should be disabled.
http://d.puremagic.com/issues/show_bug.cgi?id=3438
The more I think of it, the more imperious it becomes that we allow
default constructors that execute code. The main question is what to
do about .init.
Andrei
I'd suggest ditching it and enforce explicit member initialization
(unless a variable is nullable). This will also remove a lot of bloat
from executables.
I don't understand. The problem right now is that even of all fields are
explicitly intialized, e.g.
struct A {
Widget x = null;
double d = 0;
int i = -1;
}
there is still no ability to execute code upon initialization, e.g.
force A to contain a non-null Widget.
Andrei
Dmd2 on Mac OS X 10.6
Apparently, dmd2 for Mac is not compatible with Snow Leopard (I haven't checked dmd1 though). The doc says "for Mac OSX 10.5", not "for Mac OSX 10.5+", so I have been warned... ;-) I naively tried to rebuild dmd from source, linking with the 10.6 SDKs, and forcing 32bit, but this doesn't help. (BTW, I had to change #include "../mars/mars.h" to #include "../mars.h" in dwarf.c and machobj.c for the build to succeed.) Dmd compiles my D files ok, but the executables raise strange errors like "Bus error". So I guess it's the code generation that isn't up-to-date. Did I miss something or do I have to wait for a compatible dmd? Thanks Nicolas
Re: this() not executing code on structs
On Fri, 23 Oct 2009 18:46:47 +0400, Andrei Alexandrescu
wrote:
Don wrote:
Bartosz Milewski wrote:
Andrei Alexandrescu Wrote:
this() { myCount = count++; } // ERROR
It's worse than that. Try this:
struct foo {
this(int dummy = 0) { writeln("Default constructor");}
}
foo x = foo();
Nothing gets printed. If default constructors are disallowed, so
should constructors with all parameters defaulted.
Ouch.
It's because it's interpreting foo() as a struct literal.
If a struct has any constructors, struct literals should be disabled.
http://d.puremagic.com/issues/show_bug.cgi?id=3438
The more I think of it, the more imperious it becomes that we allow
default constructors that execute code. The main question is what to do
about .init.
Andrei
I'd suggest ditching it and enforce explicit member initialization (unless
a variable is nullable). This will also remove a lot of bloat from
executables.
Re: this() not executing code on structs
Don wrote:
Bartosz Milewski wrote:
Andrei Alexandrescu Wrote:
this() { myCount = count++; } // ERROR
It's worse than that. Try this:
struct foo {
this(int dummy = 0) { writeln("Default constructor");}
}
foo x = foo();
Nothing gets printed. If default constructors are disallowed, so
should constructors with all parameters defaulted.
Ouch.
It's because it's interpreting foo() as a struct literal.
If a struct has any constructors, struct literals should be disabled.
http://d.puremagic.com/issues/show_bug.cgi?id=3438
The more I think of it, the more imperious it becomes that we allow
default constructors that execute code. The main question is what to do
about .init.
Andrei
Re: No header files?
On 23/10/2009 14:44, Michel Fortin wrote: On 2009-10-23 03:52:10 -0400, Yigal Chripun said: I was suggesting to convert *both* obj files and lib files to llvm bit-code. such library files will still contain the metadata. what I ultimately want is to have something similar in concept to .net asseblies/java Jars but with native code (no VM involved). LLVM provides the infrastructure to do exactly this: the compiler generates platform neutral D-assemblies (in llvm bitcode) that can be used on any architecture/OS/llvm-compiler. This would also allow us to use libraries written in other languages when there's an appropriate llvm compiler for them (Ruby, scheme, python, etc). The LLVM bitcode is too much low-level for that. It won't carry enough information about types for correct type checking in D, and it cannot express templates. True, you can express arbitrary metadata in bitcode, but that'd be a whole new format to create and support... Perhaps the solution is to embed the "header file" (I mean the '.di' file) into the generated object file itself, and make DMD check existing object files for an embedded interface. That could work independently of the object file format too. I like this idea if that's possible to do. And this would require less code since .di files are already handled by dmd. It still leaves the object files themselves platform specific - objects generated by two different compilers cannot be used in the same executable. But this is a much bigger problem to tackle.
Re: this() not executing code on structs
Bartosz Milewski wrote:
Andrei Alexandrescu Wrote:
this() { myCount = count++; } // ERROR
It's worse than that. Try this:
struct foo {
this(int dummy = 0) { writeln("Default constructor");}
}
foo x = foo();
Nothing gets printed. If default constructors are disallowed, so should
constructors with all parameters defaulted.
Ouch.
It's because it's interpreting foo() as a struct literal.
If a struct has any constructors, struct literals should be disabled.
Re: [OT] What should be in a programming language?
Denis Koroskin Wrote: > On Fri, 23 Oct 2009 16:42:31 +0400, Jason House > wrote: > > [snip] > > I would have a type type, usable for both compile time and run time > > reflection. > > > > I'd separate that into built-in "type" and library "Type" types. I don't really understand how you're envisioning use of types. Can you elaborate a bit more? I'd normally assume the library Type class would be the same as used by the compiler. That would seem to keep things clean/complete, but there's no reason someone couldn't make an enhanced wrapper which would also be usable at compile time > > I've probably forgotten a number of basic things, but that should be > > enough for now. > > I believe templates are better be written in imperative style. That's why > a built-in "type" type is needed. Absolutely! Do you have any inspirational examples? > Great list. Thanks > I believe with upcoming finalization of D2 some of us are > already looking into future and D3 so keep thinking. While you get your > inspiration from D, D could also adopt some of your suggestions. Maybe. Somehow I think most of my list is too extreme. D has even moved away from some of the stuff in my list. (for example, in used to be scope const)
Re: [OT] What should be in a programming language?
On 23/10/2009 14:42, Jason House wrote:
I've been thinking lately about what my ideal programming language
would look like and what I might write if I tried to create one.
Below is a short list of big things I'd do. What do you think of my
ideas? What would you do?
I'd look to D and Scala for inspiration, but want to allow better
reasoning about code.
I'd use D's transitive const and use transitive pure instead of
transitive immutable.
Functions can't effect glabal variables unless marked as such. I'll
have to learn what a monad is so that some side effects can be
hidden?
By default, a function can not keep its variables past function
scope. If a parameter or local variable is to remain for longer it
must be marked as such in its type.
Similarly, all function arguments will default to (transitive) const.
Any mutable arguments must be marked as such. I'm unsure if ref
arguments should come in a final and non-final form. One nice side
effect of this is that value types vs. reference types don't require
special consideration.
I'd probably do away with out arguments in favor of return tuples.
All types are not nullable by default. T and T? seem reasonable
enough. I'd probably twist that a bit and use a beefed up variable
declaration similar to scala. "pure? x: T = ..." would be a nullable
immutable variable of type T.
Compile time capabilities would exceed D's. I'm thinking of a simple
marker to make anything compile time (i.e. #). #if would be like
static if. #pure would be a manifest constant. An array with some
compile time values would be easy [foo(7), #bar(8)]. This also means
#switch and #foreach would exist (among other things). Generics with
compile time arguments become templates.
I would have a type type, usable for both compile time and run time
reflection.
I've probably forgotten a number of basic things, but that should be
enough for now.
my list would be similar:
non-nullable references by default, concurrency semantics (I liked
Bartosz' design), transitive const and everything is const by default,
immutable as part of the concurrency ownership design,
functions would be defined as in ML: they take one tuple argument and
return one tuple argument
i don't like the #if, etc idea and would prefer a proper AST macro
system with proper hygiene
I'd remove static from the language completely and instead would have
metaclasses.
other OOP changes - better separation between sub-typing and sub-classing:
type interfaceA extends interfaceB, interfaceC {}
implementation implA extends implB, implC implements interfaceA,
interfaceD{}
auto obj = interfaceA.new(); // returns an implementation, e.g. implA
ionstead of the classic:
class A {}
class B: A {}
we'll have:
type A {}
type B extends A {}
implementation A implements A{}
implementation B extends implementation A implements B {}
everything is an object and no special treatment for specific types
Re: Semicolons: mostly unnecessary?
On Fri, 23 Oct 2009 07:09:01 -0500, Andrei Alexandrescu wrote: >Max Samukha wrote: >> On Thu, 22 Oct 2009 23:21:25 +0200, bambo wrote: >> >>> Walter Bright schrieb: Adam D. Ruppe wrote: Ifthepointisntplainobviousfromtheabovefewersymbolsmostcertainly doesNOTmeanalanguageisnecessarilyeasiertoparseSymbolsgiveus aparsinganchorperiodsinasentencearentstrictlynecessarywecould putoneperlineorjustfigureoutwheretheybelongbyparsingthecontext Butthatsfairlyobviouslymuchharderthanusingperiodstofollowwhere youareSemicolonsarethesamething (Fixed that for you!) >>> Walter, what a remarkable proove the semicolon helps us all a lot! >>> You are so BRIGHT! You are so creative and intelligent! >>> >>> I LOVE YOU! >> >> This is one of Walter's proofs that don't prove anything. Spaces >> between words are *not redundant*. > >In Chinese they are. > >Andrei You are right.
Re: No header files?
AJ, el 22 de octubre a las 22:08 me escribiste: > > I'm still not clear on exactly what you plan on doing. > > "Traditional" (read C/C++ like) software development. > > > If you plan on generating the function prototypes > > Nope. I plan on hand-crafting header files before I create any > implementation files. > > > in a .d file and filling out the bodies later, go for it. > > Oh, by "generating" (bad choice of word), you meant "writing". Yes I do. > > > If you plan on hand writing the .di file > > Ooops! No I don't! Yes, I will be "modeling" via header files. May I suggest something? If you want to "model via header files", write .d files with just declarations (skip implementations). You'll end up with hand written .di (headers) files, but in a .d files, so you can still automatically generate .di files from it. Use the .d files as an import in other modules (i.e., don't provide hand written .di files only). Then, when you want to start implementing your "model", just add the bodies to the functions in the "modeled" .d file. The effect in the development process is the same as hand writing .h files and progressively fill the .cpp files with the implementation, but you are doing all the work in just *one* place (the .cpp/.d files) and generating the headers files (.h/.di) from that. What problems do you find in that scheme? -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Soy como una mosca, parada en el agua. Y vos sos un transatlántico, querés nadar a mi lado. Y me estás ahogando.
Re: [OT] What should be in a programming language?
On Fri, 23 Oct 2009 16:42:31 +0400, Jason House wrote: I've been thinking lately about what my ideal programming language would look like and what I might write if I tried to create one. Below is a short list of big things I'd do. What do you think of my ideas? What would you do? I'd look to D and Scala for inspiration, but want to allow better reasoning about code. I'd use D's transitive const and use transitive pure instead of transitive immutable. Functions can't effect glabal variables unless marked as such. I'll have to learn what a monad is so that some side effects can be hidden? Agreed. By default, a function can not keep its variables past function scope. If a parameter or local variable is to remain for longer it must be marked as such in its type. A good idea probably. Similarly, all function arguments will default to (transitive) const. Any mutable arguments must be marked as such. I'm unsure if ref arguments should come in a final and non-final form. One nice side effect of this is that value types vs. reference types don't require special consideration. I'd probably do away with out arguments in favor of return tuples. Yes, it's reasonable. All types are not nullable by default. T and T? seem reasonable enough. I'd probably twist that a bit and use a beefed up variable declaration similar to scala. "pure? x: T = ..." would be a nullable immutable variable of type T. Yup! Compile time capabilities would exceed D's. I'm thinking of a simple marker to make anything compile time (i.e. #). #if would be like static if. #pure would be a manifest constant. An array with some compile time values would be easy [foo(7), #bar(8)]. This also means #switch and #foreach would exist (among other things). Generics with compile time arguments become templates. Nice idea that solves some of the D issues quite gracefully. I would have a type type, usable for both compile time and run time reflection. I'd separate that into built-in "type" and library "Type" types. I've probably forgotten a number of basic things, but that should be enough for now. I believe templates are better be written in imperative style. That's why a built-in "type" type is needed. Great list. I believe with upcoming finalization of D2 some of us are already looking into future and D3 so keep thinking. While you get your inspiration from D, D could also adopt some of your suggestions.
Re: Semicolons: mostly unnecessary?
AJ Wrote: > Walter Bright wrote: > > AJ wrote: > >> It just does full text searches. Advanced searching (by subject, > >> poster etc.) is not available as in Google Groups (as far as I can > >> tell). I would like to search subject lines only. > > > > > > It's not google groups. It's google. > > It's not that lame ass shit, I was trying to research 70 thousand posts (70 > thousand? whoa that's a lot))... hello! Me thinks that the use of semicolons should be optional. Therefore you have 10 options: use a programming language that has semicolons in its syntax, or use a programming language that does not have semicolons in its syntax. And if you don't like that answer, consider that a semicolon is otherwise what's left after you have half of your intestines removed.
Re: this() not executing code on structs
On Thu, 22 Oct 2009 12:50:21 -0400, grauzone wrote:
dsimcha wrote:
== Quote from grauzone (n...@example.net)'s article
Andrei Alexandrescu wrote:
I'd really like to know why "scope x = new X();" is "unsafe", while
encouraging doing exactly the same with structs seems to be a perfectly
fine idea. Allocating structs on the stack is obviously not any safer
than with classes. I don't remember the exact reasons why you wanted to
turn "scope" into a library feature, but I think I remember something
about discouraging it for safety reasons; please forgive me is this is
wrong.
Because classes in D are always passed by pointer. (Technically
references, but
really they're just pointers under the hood.) Returning a scope
(stack-allocated)
class from a function is equivalent to escaping a pointer to a stack
variable.
Returning a struct is done by value, just like returning an int.
(I'm talking about scope classes as declared in "scope class T { ... }")
Your original question was about the statement "scope x = new X()", which
can be done on any type of class, even non-scope ones.
But you can't return scope classes from a function. You can't pass them
as ref parameters either. They're designed to be safe.
On the other hand, you can pass struct pointers all the way you want
around, and it's damn unsafe.
I don't get this "structs are safe because they are value types"
argument anyway, because the this pointer for structs is a
pointer/reference anyway. If it's trivial to break that "safety", can
you really call it "safety"?
Passing struct pointers is not always the norm. Passing class references
*is* the norm (and actually the only way), even for scope classes, so
there is much more chance for escape.
Scope is really a dangerous hack to allocate a *reference type* on the
stack.
It's dangerous and kludgey, but in a performance-oriented language it's
a
necessary evil.
You could say the same about structs.
You have to go out of your way to pass a struct by reference. You *can't*
possibly pass a class by value, so they are more dangerous.
In order to make scope safer, it has to be a type modifier in addition to
a storage class, so the compiler can make reasonable decisions (like
disallowing implicit casting to a non-scope version).
Why do all objects have monitor pointers anyway? The idea, that every
object can act as lock, is a really bad one. But this is off-topic...
All objects have a *placeholder* for a lock, which isn't allocated until
the object is locked for the first time. It's a very pervasive idea in
other successful languages like Java and C#. Having used it extensively
in C#, I find it very easy to use and well designed.
However, in C#, there is support for conditions on objects as well, which
isn't "builtin" for D. IMO, mutexes without conditions is severely
limiting. The library condition variables aren't as nice as C#'s builtin
conditions.
-Steve
[OT] What should be in a programming language?
I've been thinking lately about what my ideal programming language would look like and what I might write if I tried to create one. Below is a short list of big things I'd do. What do you think of my ideas? What would you do? I'd look to D and Scala for inspiration, but want to allow better reasoning about code. I'd use D's transitive const and use transitive pure instead of transitive immutable. Functions can't effect glabal variables unless marked as such. I'll have to learn what a monad is so that some side effects can be hidden? By default, a function can not keep its variables past function scope. If a parameter or local variable is to remain for longer it must be marked as such in its type. Similarly, all function arguments will default to (transitive) const. Any mutable arguments must be marked as such. I'm unsure if ref arguments should come in a final and non-final form. One nice side effect of this is that value types vs. reference types don't require special consideration. I'd probably do away with out arguments in favor of return tuples. All types are not nullable by default. T and T? seem reasonable enough. I'd probably twist that a bit and use a beefed up variable declaration similar to scala. "pure? x: T = ..." would be a nullable immutable variable of type T. Compile time capabilities would exceed D's. I'm thinking of a simple marker to make anything compile time (i.e. #). #if would be like static if. #pure would be a manifest constant. An array with some compile time values would be easy [foo(7), #bar(8)]. This also means #switch and #foreach would exist (among other things). Generics with compile time arguments become templates. I would have a type type, usable for both compile time and run time reflection. I've probably forgotten a number of basic things, but that should be enough for now.
Re: No header files?
On 2009-10-23 03:52:10 -0400, Yigal Chripun said: I was suggesting to convert *both* obj files and lib files to llvm bit-code. such library files will still contain the metadata. what I ultimately want is to have something similar in concept to .net asseblies/java Jars but with native code (no VM involved). LLVM provides the infrastructure to do exactly this: the compiler generates platform neutral D-assemblies (in llvm bitcode) that can be used on any architecture/OS/llvm-compiler. This would also allow us to use libraries written in other languages when there's an appropriate llvm compiler for them (Ruby, scheme, python, etc). The LLVM bitcode is too much low-level for that. It won't carry enough information about types for correct type checking in D, and it cannot express templates. True, you can express arbitrary metadata in bitcode, but that'd be a whole new format to create and support... Perhaps the solution is to embed the "header file" (I mean the '.di' file) into the generated object file itself, and make DMD check existing object files for an embedded interface. That could work independently of the object file format too. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Targeting C
Yigal Chripun wrote: On 23/10/2009 13:02, bearophile wrote: Chris Nicholson-Sauls: I prefer this (Scala): list = list ++ (0 to 10) That's quite less readable. Scala sometimes has some unreadable syntax. Python has taught me how much useful a readable syntax is :-) Designing languages requires to find a balance between several different and opposed needs. Bye, bearophile how about this hypothetical syntax: list ~= [0..10]; I'm not sure what the type of "list" is supposed to be, but this works today for arrays: list ~= array(iota(0, 10)); Andrei
Re: Semicolons: mostly unnecessary?
Max Samukha wrote: On Thu, 22 Oct 2009 23:21:25 +0200, bambo wrote: Walter Bright schrieb: Adam D. Ruppe wrote: Ifthepointisntplainobviousfromtheabovefewersymbolsmostcertainly doesNOTmeanalanguageisnecessarilyeasiertoparseSymbolsgiveus aparsinganchorperiodsinasentencearentstrictlynecessarywecould putoneperlineorjustfigureoutwheretheybelongbyparsingthecontext Butthatsfairlyobviouslymuchharderthanusingperiodstofollowwhere youareSemicolonsarethesamething (Fixed that for you!) Walter, what a remarkable proove the semicolon helps us all a lot! You are so BRIGHT! You are so creative and intelligent! I LOVE YOU! This is one of Walter's proofs that don't prove anything. Spaces between words are *not redundant*. In Chinese they are. Andrei
Re: Mini proposal: rename float.min to float.min_normal
Don wrote: This is another small imperfection we should get rid of. The floating point types have a property called ".min", but unlike the integer ".min", it's not the minimum! I've always hated that with a passion. Yes Don, great initiative. Let's change that crap once and for all. I'd consider using minNormal, but you make a good point that _ is already present. ++vote for patching. There are a couple of places in Phobos that need changing, I can operate them. Andrei
Re: Targeting C
On 23/10/2009 13:02, bearophile wrote: Chris Nicholson-Sauls: I prefer this (Scala): list = list ++ (0 to 10) That's quite less readable. Scala sometimes has some unreadable syntax. Python has taught me how much useful a readable syntax is :-) Designing languages requires to find a balance between several different and opposed needs. Bye, bearophile how about this hypothetical syntax: list ~= [0..10];
Re: No header files?
On 23/10/2009 12:37, Walter Bright wrote: Yigal Chripun wrote: that's a different use case. *If* full sources are available than I could just compile everything myself. What we're talking about is commercial companies that do not provide full sources. In Java this is trivial - just provide jar(s), in .Net it's trivial - just provide assemblies. in D you need to provide both a library file *and* di header files. I just don't see how having another file is any sort of burden. People have been doing it for a very long time. the disadvantages of this were mentioned several times in this thread. People have also used horses for transportation for a very long time and yet they got replaced by cars and planes. I was suggesting to convert *both* obj files and lib files to llvm bit-code. such library files will still contain the metadata. I understand, but it's a lot of code to write to eliminate a file - and with other downsides like not being human readable. it's mostly integration glue code but it would be much easier to do in a compiler that already uses LLVM as its backend like LDC. I also agree with other people that said that in the long term they (and I) would like to see the reference implementation (DMD) based on LLVM. There are all those benchmarks by bearophile and others that show weak spots in DMD compared to LLVM. As a D user I'd like to get all the performance benefits from a modern otimizing back-end without the need for you to spend your precious time on reinventing the wheel in the DMD backend. If the reference implementation relies on LLVM we get all the optimizations for free and you'll have more time to concentrate on the D language itself. what I ultimately want is to have something similar in concept to .net asseblies/java Jars but with native code (no VM involved). LLVM provides the infrastructure to do exactly this: the compiler generates platform neutral D-assemblies (in llvm bitcode) that can be used on any architecture/OS/llvm-compiler. This would also allow us to use libraries written in other languages when there's an appropriate llvm compiler for them (Ruby, scheme, python, etc). Right now, you can hook D up to any language that supports a C interface. It's not necessary to convince them to use LLVM, too. No need to convince anyone - many such projects are already on their way pypy for python, rubinious for ruby, something for scheme, clang for c/c++/objective-c/objective-c++, etc.. the current way requires to write/maintain bindings and what if a specific project doesn't provide a C API? in .NET you can use assemblies generated from any .NET language in your project. For example, you can write a C# application that uses an assembly generated from a F# lib. I guess in a way, I'm suggesting to use LLVM as an open .net like platform with native complation in mind instead of VM and managed code. Another issue that's not mentioned here is shared libraries and D. there's no one simple way to have D shared libraries, and especially on windows (90% market share...) dlls are *not* a solution at all. there are 3rd party tools like DDL but I'd like to see *one* solution that works on all platforms and directly supported by D. major D libraries need to be shared libs - the runtime, the stdlib, the GUI libs, etc.. Shared libraries are inherently not portable from system to system. only if you consider dlls and so. Java jars are portable. so do .net assemblies.
[BUG] Linker produces no output but returns 0
Hi all,
I've got a problem with DMD linker on Windows.
I've got one file written in C and one in D, both are attached.
I build a working executable on Linux without any problems using:
$ gcc `sdl-config --cflags` -c -o sdl.o sdl.c
$ dmd -c stuff.d
$ dmd sdl.o stuff.o -L-lSDL -L-lpthread -ofp1
I tried to build it on Windows. I downloaded dmd.2.035.zip, dmc.zip
and an SDL development package for Windows. The code was compiled
without problems:
$ dmc sdl.c -c -I path/to/SDL/include -I /mingw/include
$ dmd -c stuff.d
stuff.obj and sdl.obj were created. Adding "-I /mingw/include" was
necessary because without it compilation failed due to lack of
"strings.h" header file.
$ dmd sdl.obj stuff.obj path/to/SDL.lib -ofp1.exe
The linker returned 0 but p1.exe was not built. A file called p1.map
was created though. I also tried the following command:
$ link stuff+sdl,p1.exe,,path/to/SDL.lib
but the results were similar.
What might be a reason of this bug? Are you aware of such problems?
Best regards,
--
Jan Stępień
#include
#include "SDL.h"
#define SCREEN_WIDTH (640)
#define SCREEN_HEIGHT (480)
SDL_Surface *screen;
/*
* From http://www.libsdl.org/intro.en/usingvideo.html
*/
void
putpixel(unsigned x, unsigned y, Uint8 R, Uint8 G, Uint8 B)
{
Uint32 color = SDL_MapRGB(screen->format, R, G, B);
if ( SDL_MUSTLOCK(screen) ) {
if ( SDL_LockSurface(screen) < 0 ) {
return;
}
}
switch (screen->format->BytesPerPixel) {
case 1: { /* Assuming 8-bpp */
Uint8 *bufp;
bufp = (Uint8 *)screen->pixels + y*screen->pitch + x;
*bufp = color;
}
break;
case 2: { /* Probably 15-bpp or 16-bpp */
Uint16 *bufp;
bufp = (Uint16 *)screen->pixels + y*screen->pitch/2 + x;
*bufp = color;
}
break;
case 3: { /* Slow 24-bpp mode, usually not used */
Uint8 *bufp;
bufp = (Uint8 *)screen->pixels + y*screen->pitch + x;
*(bufp+screen->format->Rshift/8) = R;
*(bufp+screen->format->Gshift/8) = G;
*(bufp+screen->format->Bshift/8) = B;
}
break;
case 4: { /* Probably 32-bpp */
Uint32 *bufp;
bufp = (Uint32 *)screen->pixels + y*screen->pitch/4 + x;
*bufp = color;
}
break;
}
if ( SDL_MUSTLOCK(screen) ) {
SDL_UnlockSurface(screen);
}
SDL_UpdateRect(screen, x, y, 1, 1);
}
int
init_video(char doublebuf, char fullscreen)
{
Uint32 flags = 0;
if (doublebuf)
flags |= doublebuf;
if (fullscreen)
flags |= SDL_FULLSCREEN;
if (SDL_Init(SDL_INIT_VIDEO) != 0) {
fprintf(stderr, "Unable to initialize SDL: %s\n", SDL_GetError());
return 0;
}
atexit(SDL_Quit);
screen = SDL_SetVideoMode(SCREEN_WIDTH, SCREEN_HEIGHT, 16, flags);
if (screen == NULL) {
fprintf(stderr, "Unable to set video mode: %s\n", SDL_GetError());
return 0;
}
SDL_WM_SetCaption("Window Title", "Icon Title");
return 1;
}
stuff.d
Description: Binary data
Re: Targeting C
Chris Nicholson-Sauls: > I prefer this (Scala): > list = list ++ (0 to 10) That's quite less readable. Scala sometimes has some unreadable syntax. Python has taught me how much useful a readable syntax is :-) Designing languages requires to find a balance between several different and opposed needs. Bye, bearophile
Re: Mini proposal: rename float.min to float.min_normal
Don:
> such as X86_64 and D_InlineAsm_X86<
I don't like the identifier that denotes D2 code ("D_Version2").
> If there is no objection to this, I will create a patch. It's very simple.
I usually like all your proposals about floating point numbers :-)
Bye,
bearophile
Re: Semicolons: mostly unnecessary?
Walter Bright wrote: > AJ wrote: >> It just does full text searches. Advanced searching (by subject, >> poster etc.) is not available as in Google Groups (as far as I can >> tell). I would like to search subject lines only. > > > It's not google groups. It's google. It's not that lame ass shit, I was trying to research 70 thousand posts (70 thousand? whoa that's a lot))... hello!
Re: IDE for D? Recommendations?
AJ Wrote: > Anyone have recommendations for which IDE to use to > do an evaluation of D with? On the Windows platform, with a minimal amount of configuration the Zeus IDE will quite happily run the D compiler: http://www.zeusedit.com/forum/viewtopic.php?t=2465 NOTE: Zeus is shareware Jussi Jumppanen Author: Zeus for Windows IDE
Re: No header files?
Yigal Chripun wrote: that's a different use case. *If* full sources are available than I could just compile everything myself. What we're talking about is commercial companies that do not provide full sources. In Java this is trivial - just provide jar(s), in .Net it's trivial - just provide assemblies. in D you need to provide both a library file *and* di header files. I just don't see how having another file is any sort of burden. People have been doing it for a very long time. I was suggesting to convert *both* obj files and lib files to llvm bit-code. such library files will still contain the metadata. I understand, but it's a lot of code to write to eliminate a file - and with other downsides like not being human readable. what I ultimately want is to have something similar in concept to .net asseblies/java Jars but with native code (no VM involved). LLVM provides the infrastructure to do exactly this: the compiler generates platform neutral D-assemblies (in llvm bitcode) that can be used on any architecture/OS/llvm-compiler. This would also allow us to use libraries written in other languages when there's an appropriate llvm compiler for them (Ruby, scheme, python, etc). Right now, you can hook D up to any language that supports a C interface. It's not necessary to convince them to use LLVM, too. Another issue that's not mentioned here is shared libraries and D. there's no one simple way to have D shared libraries, and especially on windows (90% market share...) dlls are *not* a solution at all. there are 3rd party tools like DDL but I'd like to see *one* solution that works on all platforms and directly supported by D. major D libraries need to be shared libs - the runtime, the stdlib, the GUI libs, etc.. Shared libraries are inherently not portable from system to system.
Re: Who's using structs nested in functions?
On 2009-10-22 18:11:01 +0200, Andrei Alexandrescu said: Fawzi Mohamed wrote: On 2009-10-22 16:33:01 +0200, Jeremie Pelletier said: bearophile wrote: Andrei Alexandrescu: With nested structs, however, you can't do much. You can pass them to a template, but I can't see some solid use cases there. My understanding is that nested structs have been implemented for completeness and consistency with nested classes. Any good example of nested struct uses? I have used nested static structs sometimes, when I need a struct just inside a function (like the main()) to avoid polluting the outer scope with the struct name. Do you want to remove them from D2? Bye, bearophile I've had similar uses, some win32 api routines require custom structs like BITMAPINFO, nested structs are neat to declare the struct right before its only usage. However I don't think having a closure for that struct is really needed, nested functions already perform that task very well, and I use those quite often. Jeremie I use structs in nested functions as context for parallel recursive loops, actually my code would be nicer if circular referring structs would be allowed in nested functions (at the moment this is not possible, even with forward references). Fawzi Could you prepend "static" in front of their definition and still have them work? Andrei Sure, I thought nested structures were always static, and did not have access to the context, as classes do. Fawzi
Re: Who's using structs nested in functions?
On 2009-10-23 12:11:20 +0200, Fawzi Mohamed said: On 2009-10-22 18:11:01 +0200, Andrei Alexandrescu said: Fawzi Mohamed wrote: On 2009-10-22 16:33:01 +0200, Jeremie Pelletier said: bearophile wrote: Andrei Alexandrescu: With nested structs, however, you can't do much. You can pass them to a template, but I can't see some solid use cases there. My understanding is that nested structs have been implemented for completeness and consistency with nested classes. Any good example of nested struct uses? I have used nested static structs sometimes, when I need a struct just inside a function (like the main()) to avoid polluting the outer scope with the struct name. Do you want to remove them from D2? Bye, bearophile I've had similar uses, some win32 api routines require custom structs like BITMAPINFO, nested structs are neat to declare the struct right before its only usage. However I don't think having a closure for that struct is really needed, nested functions already perform that task very well, and I use those quite often. Jeremie I use structs in nested functions as context for parallel recursive loops, actually my code would be nicer if circular referring structs would be allowed in nested functions (at the moment this is not possible, even with forward references). Fawzi Could you prepend "static" in front of their definition and still have them work? Andrei Sure, I thought nested structures were always static, and did not have access to the context, as classes do. Fawzi Ok I see that indeed in D2.0 struct have a pointer to the context, no I don't use that. Fawzi
Re: IDE for D? Recommendations?
On 10/23/09 04:58, AJ wrote: Anyone have recommendations for which IDE to use to do an evaluation of D with? I don't need powerful capabilities as I'm just looking to write some code and get a feel for some things in D. A bundle would be great. Also, I think it would be fun to look at the libraries during the eval. "Eval" is too strong... I just wanna play around with D a little bit in my spare time. If I can't be up an running in less than an hour, including any reading necessary to get set up, I'll have to save it for another time. I definitely don't want to be at a commandline prompt. All comments/recommendations/opinions welcomed. (Thanks in advance). I would recommend using Eclipse with Descent: http://www.dsource.org/projects/descent
Re: No header files?
On 10/23/09 05:08, AJ wrote: "BCS" wrote in message news:a6268ffbc7d8cc213dc5fee...@news.digitalmars.com... Hello aJ, "BCS" wrote in message news:a6268ffbc158cc2111f3e3b...@news.digitalmars.com... Hello aJ, You sound angry that your feature is not a fit for my development process. I think the frustration here is that you seem to be saying that you can't do something in D that you want to do but we have yet to figure out what it is. No, not at all. I realized far back in this thread that I can develop in D as I do now in C++ (header files come first). The thread went on with people trying to convince me how wrong that process is (?). I'm still not clear on exactly what you plan on doing. "Traditional" (read C/C++ like) software development. If you plan on generating the function prototypes Nope. I plan on hand-crafting header files before I create any implementation files. in a .d file and filling out the bodies later, go for it. Oh, by "generating" (bad choice of word), you meant "writing". Yes I do. If you plan on hand writing the .di file Ooops! No I don't! Yes, I will be "modeling" via header files. and then writing the implementation in a .d file... ah... that's a bad idea (for one there is no error checking between a .di file and the implementation file). Now you get what I was saying above! Yes? O! You mean that .di files are NOT like C++ header files. I think I see what you mean. Other people have told me I could work the same way I currently do in C++, but apparently, there is a big paradigm shift in the development model between C++ and D. I never even considered that D meant changing the process. Very, very good info I am getting here. Maybe I asked too soon about a D IDE, as I can't invest as much time (brainpower actually) as required to get my mind around the "whole smear" right now. I may just concentrate on select features of D for now (as I have been doing). I can't see why it's so important for your development process to have the declaration and implementation of classes and methods in separate files. If you want a person to develop the declaration and another to do the implementation why not just use a .d file and write the methods with empty bodies and then hand over the file to the person how will do the implementation?
Re: Semicolons: mostly unnecessary?
On Thu, 22 Oct 2009 23:21:25 +0200, bambo wrote: >Walter Bright schrieb: >> Adam D. Ruppe wrote: >> >> Ifthepointisntplainobviousfromtheabovefewersymbolsmostcertainly >> doesNOTmeanalanguageisnecessarilyeasiertoparseSymbolsgiveus >> aparsinganchorperiodsinasentencearentstrictlynecessarywecould >> putoneperlineorjustfigureoutwheretheybelongbyparsingthecontext >> Butthatsfairlyobviouslymuchharderthanusingperiodstofollowwhere >> youareSemicolonsarethesamething >> >> (Fixed that for you!) > >Walter, what a remarkable proove the semicolon helps us all a lot! >You are so BRIGHT! You are so creative and intelligent! > >I LOVE YOU! This is one of Walter's proofs that don't prove anything. Spaces between words are *not redundant*. And we are talking about *redundant* semicolons in programs where sentences (statements) are mostly placed each on its own line, unlike human languages where sentences are separated by points. New lines between statements are separators that make semicolons redundant. Anyway, I agree that semicolons should stay. However, the reasons are different.
Re: Mini proposal: rename float.min to float.min_normal
Don Wrote: > The floating point types have a property called ".min", but unlike the > integer ".min", it's not the minimum! That bothered me too when I was writing about it before; I felt embarrassed when explaining that it was not actually the minimum. :) Ali
Re: creal.re and creal.im are not lvalues: is that intentional?
Denis Koroskin wrote: For some reason compiler rewrites someComplexVar.re and someComplexVar.im into cast(real)someComplexVar and cast(ireal)someComplexVar respectively, which results in those variables being non-lvalues and me being unable to update either of a properties independently of each other. As one of the consequences, I can't set imaginary part of a complex variable to signalling nan: real snan = real.init; // reals are signalling nans by default creal c = ...; //c.im = snan; // doesn't work c = snan + snan * 1i; assert(isSignallingNan(c.re)); // pass assert(isSignallingNan(c.im)); // fail c = snan + cast(ireal)snan; // doesn't work either I know complex types are scheduled for deprecation but I'm still confused. I don't know whether the current behaviour is intentional, but in std.complex.Complex, which is supposed to replace the built-in types, Complex.re and Complex.im are ordinary public member variables. -Lars
Re: Mini proposal: rename float.min to float.min_normal
Don wrote: This is another small imperfection we should get rid of. The floating point types have a property called ".min", but unlike the integer ".min", it's not the minimum! This naming stupidity is inherited from C++. The minimum float is -float.max. Instead, float.min is the minimum representable positive normalized number. (BTW there are also representable "subnormal" numbers between 0 and float.min. So the name 'min' is _completely_ inappropriate, it's not even the minimum absolute value). This misnaming is bad because (a) it causes confusion; and (b) it interfere with generic code, requiring special cases. We should rename this while we have the chance. I don't think we should depart too far from the C/C++ name, but anything other than ".min" will work. I propose: real.min > real.min_normal Comments: (1) Embedded underscores are probably not ideal, but they are already in use in the floating point properties mant_dig, and the rarely used max_10_exp, max_exp, min_10_exp, min_exp. They're also used in foreach_reverse, and in the built-in version identifiers, such as X86_64 and D_InlineAsm_X86. So there seems no reason to avoid them here. But if you have a much better idea for a name, speak now! After I read your floating-point article on the DMD web site that name has been bothering me too. I vote for changing it. I wouldn't worry about the underscore, as there is already precedence for using them in keywords and built-in properties. If people don't like that, we should also change the others. Would it make sense to redefine real.min to mean -real.max? It would at least be consistent with the meaning of int.min, and perhaps it would find use in generic code. -Lars
Re: No header files?
On 22/10/2009 18:52, BCS wrote: Hello Yigal, On 22/10/2009 00:57, BCS wrote: Hello Yigal, As you said, what is needed is a better lib format. we already have DDL NOW which already has most of what you described above. D can also take advantage of the LLVM framework. Does DDL or LLVM work to generate monolithic executable that use all of D's features and do so for both Win32 and *nux? Also, can I use notepad to view either of those file types? from http://llvm.org/docs/LangRef.html The LLVM code representation is designed to be used in three different forms: as an in-memory compiler IR, as an on-disk bitcode representation (suitable for fast loading by a Just-In-Time compiler), and as a human readable assembly language representation. This allows LLVM to provide a powerful intermediate representation for efficient compiler transformations and analysis, while providing a natural means to debug and visualize the transformations. The three different forms of LLVM are all equivalent. So, if your library has LLVM code representation, then it's easier to get to but just as bad as reading a ASM dump from the compiler. I'm being more than a bit sarcastic there, but keep in mind that 99% of the info I'm interested in isn't in the assembly code (function names, argument names, types, comments) and/or would be better viewed as the original source. even though it looks like ASM it is not the same. the llvm will contain the info (function names, argument names, types, comments) as metadata. visual studio has a view to see all metadata in an assembly, and D IDEs will implement a similar properties view to show the same info. comparing to original source is useless - commercial companies may want to protect their commercial secrets and provide you with only a binary file and the bare minimum to use that file in your projects. D needs to support that option. of course it would be wonderfull if everything would be open-source but D can't force this on everyone and if we want D to be mainstream it needs to support such paradigms as well. IIRC DDL wraps objects/libs with meta-data. while it will be easy to get a text representation with llvm (the equivalence that is mentioned above) why would you want to do it anyway? Automatically extracted documentation to a human format (ddoc, javadoc, etc) is much more useful and more flexible - you can get a printed manual or an interactive and easy to navigate html, you can also get all sorts of graphs and diagrams that would ease understanding of the structure of code. I'm cynical enough that I'd bet if D switches to a "smarter lib format" a lot of people would manage to forget the documentation. With the current system, the library must be shipped with, at a minimum, a human readable list of prototypes. without proper documentation people will have no way to know how to use such libraries. givven that D has DDoc to automate this process I'd say it'll encorage developers to provide proper documentation instead of just saying - go read the headers/source. the only valid IMO use case for header files is for linking libs - the compiler can handle just find binary formats for that. Truth be told I don't use .di files at all because I have yet to need to use a codebase where I didn't have full source. that doesn't reflect the needs of everyone.
Re: Mini proposal: rename float.min to float.min_normal
I agree, when i had to type float.min i was confused it it was the smallest subnormal or smallest normal float
