On 05/03/2015 08:40 AM, scott wrote:
>>> An interesting read, so it turns out you are actually quite good at C#
>>> programming then :-)
>>
>> Well, yeah, I did just spend the last 2 years writing C# code every
>> single day. ;-)
>
> Maybe you mentioned it but I forgot, what language are you writing the
> "compiler" in then?

The compiler is written in Haskell.

It probably wouldn't be hard to write the back-end in C# either - but 
the front-end would be nightmarishly horrific to write in anything less 
powerful than Haskell. (And even then, it's going to be quite hard.)

If, by some miracle, the compiler ever becomes self-hosting [which I 
consider extremely unlikely], then it will be possible to compile 
Haskell code to C# from within C#.

Actually, it's surprising how similar the C# and JavaScript backends 
have ended up being. Like, they both get driven by the same data 
structures. You could realistically write a compiler that spits out one 
or the other at the flick of a switch. (Assuming the front-end existed, 
which it doesn't.)

> You can write C# code to generate, assemble and run
> code dynamically can't you?

You *can*, in two different ways.

There's a "code DOM" that is a fancy system for generating 
syntactically-correct C# source code. (I.e., it lets you save text to a 
file, and then compile it how you could compile any other C# code.) I 
*think* they added the ability to programmatically compile it from 
within a running C# application now.

Or you can generate raw MS CIL directly, which is instantly useable. 
(But it means you have to comprehend low-level CIL stuff.)

At the moment, my computer just outputs ordinary C# source code, which 
VisualStudio can then compile. (Or, more likely, complain about.)

> I started work on a raytracer once where the
> user typed in the scene as pseudo-C# code and then it compiled it an ran
> it to render the scene - it wasn't a security hole, more like a security
> chasm :-)

Sounds a bit like the self-extracting POV-Ray scene I wrote a while 
back... ;-)

>> ...yeah, it turns out file_offset was declared as a 32-bit integer
>> rather than a 64-bit integer. (Because C doesn't define the size of
>> things, it's just left as implementation-dependent. Yay!)
>
> Yes, at least in C# you have Int32 Int64, and the MS IDE would probably
> give you a red squiggly line under something like that if you got it wrong.

Or Haskell, which gives you Int8, Int16, Int32, Int64 (and Integer, 
actually). Or Pascal. Or Smalltalk. Or Eiffel. Or, really, just about 
any programming language less ancient than C.

Considering that C was invented explicitly for the purpose of writing an 
operating system, it seems weird that it doesn't define bit-sizes, 
considering how utterly fundamental those are to all systems programming...

> I stopped using C++ a long time ago precisely for these sort of things
> that you miss and it screws everything up. Also I got so used to the
> autocomplete and help for C# in the MS IDE that the C++ one is painful
> to use now.

Yeah, as soon as you start editing C++ code, VisualStudio becomes a 
paperweight. You can't look up definitions of anything [because that's 
equivalent to solving the Halting Problem], you can't find usages of it 
[same reason], you certainly can't auto-rename stuff, it's impossible to 
determine which include file a certain identifier comes from or what 
it's type might be... It's just a painful experience.

Oh, and just because it compiles on Windows does *not* mean it will 
compile (or link) on Linux. For a start, if you are so incautious as to 
add a new source file to the project, you now have to manually edit the 
makefile [several times - because the first edit will never, ever be 
correct]. Then there's the fact that VS accepts

   template1<template2<FUBAR>>

whereas GCC demands that there must be a space (because ">>" is an 
operator)... The fun never ends!

Sometimes, I like to show people the source code to our file-analysis 
program, and then the corresponding 10-line program in Haskell. ;-)

Post a reply to this message