Re: Article about problems & suggestions for D 2.0
On 27.08.2011 19:16, Benjamin Thaut wrote:
After having used the D 2.0 programming language for a year now and
having completed 3 projects with it, I wrote a small article about the
problems I had with the D 2.0 programming language and what suggestions
I have to improve it.
http://3d.benjamin-thaut.de/?p=18
Comments and criticism welcome
As for point no. 3 (Structs not having identity):
Structs have a postblit constructor. These have access to the new struct
but not the old one. Maybe you can use this to register a new reference.
If I remember this right the old reference should be cleaned up
(unregistered) by the destructor but I'm not sure. You article implies
that the destructor is not called for every copy of the struct.
Point no. 5, "Shared":
I actually had pretty much the same trouble with the syntax for shared
delegates. The compiler output is very misleading. In the end this
syntax mostly worked:
shared(void delegate(const char[])) message_handler;
Still had to cast away the shared on the rhs expression of an assigment.
Maybe the full code can shed some light on this:
// An array of message handlers
private shared( shared(void delegate(const char[]))[] )
message_handlers;
// Function to register new handlers
public shared void hook(shared(void function(const char[]))
message_handler){
typeof(message_handlers[0]) handler_dg;
handler_dg.funcptr = cast(void function(const const(char[])))
message_handler;
synchronized(mutex)
message_handlers ~= handler_dg;
}
The typeof trick to define the handler_dg variable is there because
nothing else seemed to work.
I worked with Benjamin on the space shooter game. The above code is
actually from the logger of that project (base/logger.d).
Point no. 7, "Associative array invariance":
This was my most frequent identifiable bug source. Pretty much what
Benjamin said: it's annoying the program just crashes. However bugs like
that are easy to find with a debugger... usually.
Point no. 8, "No function overloading with template parameters":
Got the same problem while templating some functions of an overload set.
It's not possible to mix overloads with templates. That wasn't much of a
problem but converting everything to templates doesn't work ether. In
the end I used templates that generate normal function overloads and
explicitly instantiated those templates.
Happy programming
Stephan Soller
Re: Why Ruby?
On 19.12.2010 14:22, Alex_Dovhal wrote: "Stephan Soller" wrote: I don't think that the syntax improvement of chaining is worth such an effort. It adds tons of complexity for only a very limited gain. I'm not sure if I could write such self-parsed code without thinking about that pipeline. I think I don't fully understand what you mean by syntax improvement for chaining. This my code is almost possible to run but needs some time and work (to get round CTFE limitations, enhance parser). But syntax parser behind it is rather primitive, if to use external tools one can make much better syntax parsers with much less efford. I read your post in the context of method chaining with templates like filter! and map!. Looks like I missed the point. :) I think your idea is pretty impressive. Maybe useful for some high-level stuff like mathematical formulas.
Re: Why Ruby?
On 16.12.2010 20:01, Jacob Carlborg wrote:
On 2010-12-15 17:06, Stephan Soller wrote:
On 14.12.2010 20:03, Jacob Carlborg wrote:
>> …
>>
What's more important
(at least for me) is the chaining ability and how performant such
delegates actually are. From what I understood from std.functional it
wraps string expressions in delegates anyway so using
ary.map!("a*a");
is not more efficient. Please correct me if I'm wrong! The
std.functional code is definitely above my understanding.
I would though it just mixed in the string with some other code to make
a complete expression.
It does that (would there be another way?). The question is if it
creates an delegate with the expression or does it not built a delegate?
The code in question starts at line 78 of std/functional.d[1] (that is
the code related to unaryFun!()).
I'm really not sure what this code does…
[1]:
http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/functional.d#L78
Happy programming
Stephan Soller
Re: Why Ruby?
On 16.12.2010 23:33, Alex_Dovhal wrote:
"Andrej Mitrovic" wrote:
The cool thing about D is that with a little bit of string magic you
can make your own DSL's. Here's a rather hardcoded and superficial
example, but for this simple case it works:
http://pastebin.com/Xkghv1ky
Of course you'd need to build your own little DSL string parsing
functions and use regex instead of hardcoding it like that. But all
kinds of syntaxes are possible.
You are right. I tried making one. It parses things like sum !(q{ i=0:10;
i * sum!(q{ j=0:10, j!=i;i*j }) })
http://pastebin.com/mQaKXaYY -
But it doesn't work because not being CTFE friendly, and also syntax parser
is ugly because I am not strong at syntax parsing.
Note that creating good syntax parser in CTFE is rather hard, especially for
complex syntaxes like of D expressions.
Oh, if CTFE could:
1) run external process
2) do file i/o
3) use dynamic libraries
This would be much much simpler, but I guess it will not.
This features also has safety issues, but D is system language, not browser
one.
I don't think that the syntax improvement of chaining is worth such an
effort. It adds tons of complexity for only a very limited gain. I'm not
sure if I could write such self-parsed code without thinking about that
pipeline.
Re: Why Ruby?
On 15.12.2010 17:37, Andrej Mitrovic wrote:
On 12/15/10, Stephan Soller wrote:
So, _if_ we can figure out a way to do some nice chaining of such calls
we can get:
[1, 2, 3, 4, 5].filter!((e){ return e> 3; })
.map!((e){ return e*e; });
Or if you don't like delegates and don't mind obvious compile time black
magic:
[1, 2, 3, 4, 5].filter!("a> 3").map!("a * a");
You might use pipe! as an alternative:
import std.algorithm;
import std.functional;
import std.stdio;
void main()
{
int[] arr = [1, 2, 3, 4, 5];
auto result = pipe!( filter!("a>3"), map!("a * a") )(arr);
writeln(result);
}
But I can't seem to do the same with delegates:
import std.algorithm;
import std.functional;
import std.stdio;
void main()
{
int[] arr = [1, 2, 3, 4, 5];
pipe!( filter!( (e){ return e> 3; } ),
map!( (e){ return e*e; } ) )(arr);
}
chain.d(9): Error: expression template filter(Range) is not a valid
template value argument
chain.d(9): Error: expression template map(Range) is not a valid template
value argument
Thanks for testing this out. :)
I noticed compose! and pipe! but these break my "thought flow". It's
hard to describe since I only experienced such a way of writing code in
Ruby. You can more or less write your thoughts down without much
translation or the need to go back and forth in the line. As you think
you can type… I don't need a "thought buffer" so to speak.
Having to think about if I want to call multiple collection operations
or just one right at the start breaks this flow. That the data at hand
is pushed to the end of the line (poor visibility) also don't really
help. I don't know if this is a matter preference but while deciding on
such collection operations I usually think about the data first. Only if
I know how the data is structured I start to apply operations on it.
This code
[1, 2, 3, 4, 5].filter!("a> 3").map!("a * a");
matches the that flow of thoughts. With pipe! I have to jump 2 times
within a buffer of 3 thoughts.
All that may sound very… unprofessional or "not like a real programmer".
However that kind of "mental friction" adds up and you notice that if
it's no longer there. I really agree with Matz (the creator of Ruby)
that the way you formulate your thoughts changes your thought patterns
in turn. Ruby is carefully crafted to keep the resulting thought
patterns close to the natural ones. To experienced programmers this
might be irritating at first since languages like C++, Java and even D
require some mental acrobatics to formulate what you want. It takes some
time to just think strait again if you're used to these acrobatics. Ruby
is a very interesting subject if you're interested in what programmers
think while programming.
Please note that this stuff is IMHO limited to application programming.
That is to solve hight level problems where low level work only adds
friction and is not that important (like with usual Websites). With
systems level programming this is different. When working with low-level
APIs and very machine specific problems the thought patterns are
different than the ones of application programming. The problems are
often not defined by real world needs and therefore the experience from
the real world can not help there.
This is the reason why I think D should not spend to much time with
this. It's not a design goal of D and probably would collide with other
design goals (e.g. efficient compiler implementation). If someone really
wants this kind of programming in D it's not that difficult to do, but
will cost efficiency (e.g. using real functions instead of templates). D
should not mimic Ruby nor is Ruby as bad as some might think. It's one
of the few languages that really accept that programmers are humans and
not machines. D does this too but by far not to the same extend (thats
why I still like D1 more than D2 actually).
Ruby has its applications and D has its applications. The right tool for
the right job only works if the different tools have a distinct purpose
and not try to do everything at the expense of being good at one thing.
Happy programming
Stephan Soller
Re: Why Ruby?
On 14.12.2010 20:03, Jacob Carlborg wrote:
On 2010-12-14 19:33, Stephan Soller wrote:
I think it's a matter of consistency. In Ruby blocks are used all the
time for pretty much everything. In D this isn't the case because
usually templates are used for stuff where blocks are used in Ruby
(e.g.
map, group and find in std.algorithm).
I think that the templates that take a string as a predicate is just an
ugly hack because D has a too verbose delegate syntax.
I absolutely agree with that. However I don't have a better idea how to
write it. Delegate syntax is already fairly compact in D.
For example code as this isn't very uncommon in Ruby:
[1, 2, 3, 4, 5].select{|e| e > 3}.collect{|e| e*e}
Of course this is a simplified example. Usually the collection would
contain some objects and the blocks would filter for a method call (like
"e.even?"). However I built a small D1 struct that implements a select
and collect function. With the unified function call synatax for array
with code should actually work:
[1, 2, 3, 4, 5].select((int e){ return e > 3; })
.collect((int e){ return e*e; });
It's already fairly compact. The main overhead is the parameter type and
the return statement. I don't believe this can be reduced any more
without breaking consistency of the language.
Probably not, but, for example, Scala allows very compact delegate
literals:
Array(1, 2, 3, 4, 5).select(_ > 3).collect(_ * _)
Or more verbose:
Array(1, 2, 3, 4, 5).select((x) => x > 3).collect((x, y) => x * y)
I'm not 100% sure I that the syntax is correct.
Delegates are way more verbose in other languages like PHP and
JavaScript (more or less the same syntax in both languages). Despite
that it's no problem to use it and in case of jQuery it's used very
often. I think the main reason why delegates are not used like that in D
is performance. I'm really not sure about it but I suspect that
delegates are less effective than code directly generated by a template
like map!(). I don't know how efficient templates can integrate
delegates so I just suspect that this is a performance problem.
Happy programming
Stephan Soller
PHP has a very verbose delegate syntax with explicit closures, one of
the many reasons I don't use PHP. JavaScript has quite similar syntax as
D but the "function" keyword is required, I try to use CoffeeScript
(compiles to javascript), which has a lot nicer delegate syntax, as
often I can.
D(dmd) needs to be able to inline delegates.
I'm not so much concerned about verbose delegate syntax. Personally I
don't mind using the current delegate syntax with templates like map!.
However I'm concerned about performance and parameter order. Does
someone know how delegates within templates are handled? I looked at the
source of std.algorithm and std.functional but I'm still not sure what
actually happens if you call something like
auto ary = [1, 2, 3];
map!((e){ return e*e; })(ary);
I can't test this code right now since I don't have a D2 compiler
installed at this computer but the std.algorithm source contains unit
tests with delegates.
If that now works with uniform function call syntax it could be written
like that:
auto ary = [1, 2, 3];
ary.map!((e){ return e*e; });
I don't know if chaining of such calls is possible but the above syntax
is already pretty good. Sure, it's not perfect and the "return" still is
some overhead, but I don't think it needs work. What's more important
(at least for me) is the chaining ability and how performant such
delegates actually are. From what I understood from std.functional it
wraps string expressions in delegates anyway so using
ary.map!("a*a");
is not more efficient. Please correct me if I'm wrong! The
std.functional code is definitely above my understanding.
So, _if_ we can figure out a way to do some nice chaining of such calls
we can get:
[1, 2, 3, 4, 5].filter!((e){ return e > 3; })
.map!((e){ return e*e; });
Or if you don't like delegates and don't mind obvious compile time black
magic:
[1, 2, 3, 4, 5].filter!("a > 3").map!("a * a");
I think if chaining would work like that D would already be pretty close
to the expressive power of Ruby. It's just that this kind of programming
is very dependent on the ability of built in collections and libraries
that allow such a programming style.
Happy programming
Stephan Soller
Re: Why Ruby?
On 14.12.2010 19:49, Simen kjaeraas wrote:
Stephan Soller wrote:
[1, 2, 3, 4, 5].select((int e){ return e > 3; })
.collect((int e){ return e*e; });
It's already fairly compact. The main overhead is the parameter type
and the return statement. I don't believe this can be reduced any more
without breaking consistency of the language.
The delegates can be passed by alias parameter, and then be written
without the parameter type:
@property void bar(alias t)() {
t(3);
}
void main() {
bar!((e){writeln(e);});
}
Hm, nice trick, thanks Simen. Looks interesting and more general to use.
Will try that for my next D project.
Happy programming
Stephan Soller
Re: Why Ruby?
I think it's a matter of consistency. In Ruby blocks are used all the
time for pretty much everything. In D this isn't the case because
usually templates are used for stuff where blocks are used in Ruby (e.g.
map, group and find in std.algorithm).
I think that the templates that take a string as a predicate is just an
ugly hack because D has a too verbose delegate syntax.
I absolutely agree with that. However I don't have a better idea how to
write it. Delegate syntax is already fairly compact in D.
For example code as this isn't very uncommon in Ruby:
[1, 2, 3, 4, 5].select{|e| e > 3}.collect{|e| e*e}
Of course this is a simplified example. Usually the collection would
contain some objects and the blocks would filter for a method call (like
"e.even?"). However I built a small D1 struct that implements a select
and collect function. With the unified function call synatax for array
with code should actually work:
[1, 2, 3, 4, 5].select((int e){ return e > 3; })
.collect((int e){ return e*e; });
It's already fairly compact. The main overhead is the parameter type and
the return statement. I don't believe this can be reduced any more
without breaking consistency of the language.
Delegates are way more verbose in other languages like PHP and
JavaScript (more or less the same syntax in both languages). Despite
that it's no problem to use it and in case of jQuery it's used very
often. I think the main reason why delegates are not used like that in D
is performance. I'm really not sure about it but I suspect that
delegates are less effective than code directly generated by a template
like map!(). I don't know how efficient templates can integrate
delegates so I just suspect that this is a performance problem.
Happy programming
Stephan Soller
Re: Why Ruby?
On 13.12.2010 18:39, Nick Sabalausky wrote: "Stephan Soller" wrote in message news:ie4srq$138...@digitalmars.com... On 12.12.2010 18:01, Simen kjaeraas wrote: Absolutely not. Ruby reads like Yoda-speak, while D is almost plain English. Had foreach used 'in' instead of the semicolon, only punctuation and 'ln' would be off. Unfortunately I have to disagree here. If you have well written Ruby code (like Ruby on Rails usually provides) it can usually be read like plain English. That's the reason why I dropped writing documentation comments for Ruby code: it's just redundant. This common Ruby idiom is totally Yoda-speak to me: doSomething unless condition? The order-of-execution is completely backwards. Plus the "unless" instead of "if" makes my mind pause to process an "inverted-context" because *now* seeing a "blah" really means "not", and a "!blah" no longer means "not". Yea, "(action) unless (condition)" is fairly normal English, but code has different requirements than normal speech. And besides, it's also perfectly normal, easily-understandable English to say "unless (condition), (action)", or even a negated if: "if you don't have x, do y". In fact I'd argue the English "if you don't have X, do Y" is much easier to understand than "do B unless you have C". With normal English, it's easy enough to hear "do this", and then appropriately modify it in your head when you hear it followed by "unless that". This is largely because instructions in normal English tend to be *much* simpler than instructions in code. With code, there's so many other instructions to consider that that extra little mental work of modifying something you already processed suddenly makes a difference. But if you see something start with the modifier (the condition, in this case) then your mind automatically knows it's still an incomplete thought and doesn't do a premature "commit". At least that's how my (twisted?) mind works. Also, Ruby reading like English might be part of why I'm *not* quite won over by Ruby's syntax: I'm a native English speaker and I still think English makes no sense! I'm not a native English speaker so I can't really judge how much "like English" Ruby really is. However I prefer Rubys pseudo English over some nested function calls with templates or mixins or something like that. Not that code like this is not possible in Ruby but no one actually writes such code with it (or I just haven't seen it). I avoided "unless" for about a year after learning Ruby. It gave me a headache translating it to "if not" and converting "or"s to "and"s. But over time I fund it useful to write down thoughts without translating them to "if". Maybe "(do something) unless (something)" it's only a common thought pattern in German, don't know how much it is used in English. "unless" is just a small detail and I wouldn't call it a revelation but Ruby has many small details that help you to keep your thoughts more in the problem domain and write code with less "translation" done by the brain. It _feels_ very pleasant over time, sometimes even fun. But I don't think this is something a talk or presentation can convey. One just has to use Ruby for well suited problems for some time. Happy programming Stephan Soller
Re: Why Ruby?
On 11.12.2010 10:29, "Jérôme M. Berger" wrote:
Ary Borenszweig wrote:
http://vimeo.com/17420638
A very interesting talk.
I used to like D. To write code in a high level while at the same
time being very close to the machine, with class invariants, unit
tests and many other features seemed very appealing. But I always
felt there was something wrong.
About a year ago I met Ruby. Now I find languages like Java, C#,
Python and D kind of ugly and uncomfortable. Why? Exactly because of
what it is said in that video.
This is not to start a flame war or trolling, it's just to show you
why I changed my mind so much about D, and why I think (IMHO) you
should care about naming conventions (like bearophile says), more
powerful unittests (and not having unittests integrated into the
language but rather being able to build your own test frameworks
with ease) and stop caring about being C-syntax friendly. The world
doesn't need that many semicolons and parenthesis. :-)
There is a major syntax issue with Ruby. This line:
foo(a, b)
does not mean the same thing as this line:
foo (a, b)
!!WT?
Jerome
Well, this is only a major syntax issue if you write Ruby code like you
write C code (with many parenthesis). Usually method calls in Ruby don't
contain any parenthesis:
foo a, b
Parenthesis are only used if a parameter is an expression:
foo (a + 1), b
Because of that coding style the above example is an rare edge case. I
tried it in IRB (interactive Ruby console) and your two method calls
actually do the same. The second one however generates a warning ("don't
put space before argument parentheses").
ps.: For "foo (a, b)" to really screw up "," has to be a method defined
on "a". I don't think that's possible in Ruby.
Happy programming
Stephan Soller
Re: Why Ruby?
On 13.12.2010 12:42, Simen kjaeraas wrote: Stephan Soller wrote: Absolutely not. Ruby reads like Yoda-speak, while D is almost plain English. Had foreach used 'in' instead of the semicolon, only punctuation and 'ln' would be off. Unfortunately I have to disagree here. If you have well written Ruby code (like Ruby on Rails usually provides) it can usually be read like plain English. That's the reason why I dropped writing documentation comments for Ruby code: it's just redundant. I'm only commenting on the above code, not Ruby in general. Sorry, I got that wrong then.
Re: Why Ruby?
On 12.12.2010 21:17, spir wrote:
On Sun, 12 Dec 2010 12:23:03 -0600
Andrei Alexandrescu wrote:
Going now
back to D, we can imagine the following lowering:
fun (a, b ; c) stmt
=>
fun(c, (a, b) { stmt })
It seems to me that lowering is analog to redefine "shallow" syntax (in fact,
syntactic sugar) into a deeper syntax mirroring that actual AST. The syntax tree for
foreach/iteration could be written as:
iteration:
collection: c
loopVarNames: ['a','b']
block: stmt
And generalised into:
blockOperation:
source: c
loopVarNames: ['a','b']
block: stmt
where your 'func' is a "block-wise operation". What do you think?
But I do not see in what Ruby-like syntax and point of view are clearer;
actally, I find D far more readable.
And even less what this would bring to D. This is interesting in highly
reflexive languages; even more reflexive than Ruby in fact, where one could
tweak the block at runtime. But this is not the perspective of D, I guess.
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
I think it's a matter of consistency. In Ruby blocks are used all the
time for pretty much everything. In D this isn't the case because
usually templates are used for stuff where blocks are used in Ruby (e.g.
map, group and find in std.algorithm).
I don't know if it's possible to unify the way to "pass code as an
argument" in D but that's where Ruby really shines in my opinion:
consistency in usage.
Happy programming
Stephan Soller
Re: Why Ruby?
On 12.12.2010 18:01, Simen kjaeraas wrote: so wrote: If we take a look at the very first code example from the talk it looks like this: account.people.each do |person| puts person.name end You could translate this in two ways when translating into D. First way: foreach (person ; account.people) writeln(person.name); Am i alone thinking D one better here? Absolutely not. Ruby reads like Yoda-speak, while D is almost plain English. Had foreach used 'in' instead of the semicolon, only punctuation and 'ln' would be off. Unfortunately I have to disagree here. If you have well written Ruby code (like Ruby on Rails usually provides) it can usually be read like plain English. That's the reason why I dropped writing documentation comments for Ruby code: it's just redundant. I'm not at home so I can't post a good example. However I once built a website in Ruby on Rails together with another person responsible for the content. This person had no programming experience what soever. Because I hadn't completed some backend stuff the development version of the website threw an exception and the code of the action was displayed. I was curious and asked here if she was able to understand what these lines do. She was actually able to exactly tell me what the code was doing... without ever learning about programming. I doubt this would have been possible with D code. Happy programming Stephan Soller
Re: Why Ruby?
On 12.12.2010 20:44, foobar wrote: Adam D. Ruppe Wrote: foobar wrote: D basically re-writes foreach with opApply into the ruby version which is why Ruby is *BETTER* You missed the point: there is no "Ruby version". They are the same thing. By "ruby version" I meant the syntax. I agreed already that they are implemented the same. foreach to me is a redundant obfuscation How can it be redundant? It's got the same elements the same number of times. incorrect. The difference is that D adds "special" syntax for this whereas it's just a plain method in Ruby. By calling opApply directly you get the direct "ruby version" without the redundant use of a keyword + compiler transformation. rofl.copter.each |lol| spam end foreach(lol; rofl.copter) spam Same elements, just reordered. I don't know about the each() method itself. I've never written one, but I suspect it is virtually identical to opApply too. opApply *is* the same thing as Ruby's each method. Just for the sake of correctness: Ruby too has a for-like loop that gets rewritten to the block/delegate version. for lol in rofl.copter spam end This gets rewritten to rofl.copter.each do |lol| spam end As far as I know this is a construct for ease transition from C to Ruby but is not used very much. Blocks are used very often in Ruby so using a for-loop is kind of inconsistent style. Happy programming Stephan Soller
Re: Ddoc to PDF
On 19.10.2010 15:14, Gerrit Wichert wrote: Am 17.10.2010 19:45, schrieb Walter Bright Apparently, it is fairly simple to convert plain text files to PDF. http://re-factor.blogspot.com/2010/10/text-to-pdf.html Which suggests to me it should be equally simple to create a Ddoc macro file to allow Ddoc to emit pdf files directly. Anyone want a nice weekend project to product this? I don't think that it is the best idea to produce a pdf in one step. First PDF is really complicated (and also evolves over time). Second this would require dmd to determine the layout of the generated documentation. We could easily avoid the frist point. When we just make ddoc generating xsl-fo a tool like apache fop can be used to generate pdf or html from it. This is what xsl-fo is designed for. It's not rocket science to create a xsl-fo layout. But the second problem remains. If i where a company or community writing libraries in d i would like to have some corporate identity in it. This means that I want to decide over the layout. So i would really prefer if ddoc were *additionaly* able to generate a pure semantical version of the document data that is easy to mess with an external tool. This can be a simple xml file which i can feed into my own transformation pipline. This way ddoc does the part it can really shine on, extracting the information, and delegates the rest to something that knows more about the wishes of the actual user. This shuoldn't mean that ddoc should stop generating unified standart documentation. But i think it is worth a thought to generate semantic data files on request. Gerrit I agree but maybe DDoc as it is now is already enough. I haven't looked closely at the HTML DDoc generates but from what I've seen on the D home page it looks expressive enough. This HTML code can be converted to PDF with [PrinceXML][1] and you have all the flexibility of CSS at your disposal (I know not everyone likes CSS…). Letting the compiler do the layout of the PDF generation might be overkill. It's a compiler and not a layout engine. [1]: http://www.princexml.com/ Happy programming Stephan
Re: Tuple literal syntax
On 07.10.2010 17:36, Andrei Alexandrescu wrote:
On 10/7/10 10:13 CDT, Kagamin wrote:
Andrei Alexandrescu Wrote:
struct Coord
{
int x, y, z;
}
one iota typesafer than
alias Tuple!(int, "x", int, "y", int, "z") Coord;
Is there a real need for an alternative way to declare structs?
Yes.
Andrei
I agree but I also don't agree. I like the possibility to return
multiple values (quite handy in Ruby, PHP and other languages) and
therefore we need language constructs to group multiple values and
ungroup them again.
However as soon as these fields are named it looks to me like an
ordinary structure. So why not just create something like an "anonymous
structure literal" that behaves to structures like anonymous functions
(or delegates) to functions?
This would look a lot more consistent to me than playing around with
different kinds of tuples. However I'm not sure about the details (e.g.
how would such structures handle type or alias contents).
Happy programming
Stephan
