GNOME.org
 

Re: [Vala] Hi, Is Vala what I am looking for?

On Thu, 2009-09-17 at 12:48 -0400, "Andrés G. Aragoneses" wrote:

Michael B. Trausch wrote:

For example, method names are written like_this.  This is incompatible
with java (likeThis) and C# (LikeThis) conventions.  Also, data types


But this is just a convention. I'm talking about *real* compiler issues.


Conventions are what keep the world together.  Conventions grow up
around languages.  There is a reason (other than syntax) why Vala and C#
code do not look the same, though they are similar.  Conventions matter;
you cannot disregard them.


are different and have different rules; the underlying data types are C
data types, with some extensions that are provided for by the glib and
glib-gobject libraries.


In this case, some fake class types could be created for the C# compiler
to be understood by it.


This would very quickly become impractical, I think.  I imagine you must
be underestimating the amount of work that would be required ---
assuming, anyway, that such a thing is even possible.  Vala and C# are
*not* syntax-compatible, and you seem to assume that they are.  Any
subset that might be would be pretty close to useless.  Further,
everything outside of the language but in the runtime support category
is different in both systems.  Believe me, I have and do work in both.


In short, the differences are enough that you'd not be able to use a
single unified source tree, at least not without a great deal of effort.
Of course, _anything_ is possible given enough time.  One potential
solution would be to code in neither, and instead generate the code for
both.

For example, you could write a set of GNU m4 macros that would be
processed against text input to generate the same (functionally
speaking) code for Vala and for C#.  I don't believe that such a job


I think this effort is not worth it, because you don't end up with a
language which looks like Vala or C#... What I'm talking about is if it
would be possible to write, on purpose, some piece of code that uses the
common set between Vala and C#, and thus, may be compilable by both. [*]


I agree; it's not worth it.  There are far many more differences that
you fail to consider, here.  Both systems are going to be programmed in
different ways, because they are very different in terms of how they
accomplish things.  Idioms that work in the CLI do *not* work in the
native world---and that's really just the tip of the iceberg.
C#-specific idioms may or may not make sense in Vala, depending on the
required syntax for them and whether or not Vala supports it or not.

Take a look at, for example, event-handling in Vala.  It *resembles* C#
event handling (signal firing, etc.) at the source code level.  But it's
not the same, and as far as the actual underlying work behind it, it's
far, far different.


would be terribly easy, mind you, but it would be possible.  The macros
would have to be able to effectively abstract away all of the
differences between the two worlds, though; for example, C# has the
concept of "unsafe" operations, while in Vala, everything just _is_.
(After all, Vala compiles to C.)

Among the reasons that it would be very difficult to do is that there is
a massive difference between what's provided by the libraries that can
be assumed to be available when writing Vala code, and the libraries


But let's assume we want to create just a very simple HelloWorld
executable, both compilable by C# and Vala, with no usage of libraries.
If this is possible, we could for example convert a simple C# library
(such as the class System.Console, with just the method "WriteLine")
into this "ValaSharp" language, and then create another executable on
top of it that still runs on both environments. I am not sure if I'm
explaining correctly.


You would have to:

 * Restrict yourself to the lowest union between both languages,
 * Use no runtime library support (impossible, or at the very least, 
   *EXTREMELY* impractical), because they are that different from
   each other,
 * and reinvent the wheel for a lot of things.

Using some sort of unified set of macros (which, with careful effort,
you *could* make look very similar to Vala or C#), you *could* generate
code that uses the proper stack for both systems and is functionally
equivalent.  However, that's an entirely different approach from what
you're talking about.  Still a hell of a lot of work, but it's better
than stripping the languages down to the bare metal and starting from
there on up.

It almost sounds to me like you want a C# compiler that targets real
CPUs instead of targeting the CLI?  You won't find that in Vala.


other major difference is that Vala is not garbage collected.  It uses
"assisted memory management" as opposed to garbage collection.  This
changes the way you have to think about objects in subtle ways.

Let's say we have a piece of code that can be compiled by both Vala and
C# compilers, but it leaks in Vala but not in Mono (because of the GC).
Could that piece of code be 'tweaked' in order to make it not leak in
the Vala case? If yes, we could develop a Gendarme rule that analyzes
the assembly to search for possible leaks that may occur if the source
code is compiled with the vala compiler, right?

No,


Why not?


Because Gendarme only works on binaries that are compliant with the ECMA
specs, for starters, and the output of Vala ultimately on UNIX-like
systems is ELF, and on Windows is PE32 or PE64, depending on what the
compiler outputs?  Because the type of analysis that gendarme does is
not something that is generally doable outside of the world of managed
code, because managed code houses an absolute ton of metadata about the
bytecode contained in the assembly, whereas native binaries have
debugging symbols and some extra information, but not the metadata that
makes all of that possible?

I don't know of any utility that could be used on a native binary to
analyze it for things the way that gendarme does for CLI binaries.  It
certainly *might* be possible, but there really are too many factors to
do it reliably.

You could, I suppose, try to write software that analyzes Vala source
code, but that would also be exceedingly difficult to do correctly.
It's an entirely different world from managed code.  If you want to
analyze a program on a native stack, you have to do so with a tool that
understands the assumptions made by the lower pieces in the software and
hardware stack.  This is far easier for VM-type systems like Java and
the CLI because the virtual CPU is very well defined and, again, it
contains much more metadata about the program code.


but with Vala, you would use standard tools that are readily
available.  You can use gdb for debugging, gprof for function profiling,


I know, but what I'm trying to avoid is the use of runtime tools in
favor of statical analysis tools (Gendarme).


Why?  gendarme is a nice tool, but it's less than useful; runtime tools
are far more helpful and can yield far better (and more relevant)
information about the program, including where the hotspots are, where
the bottlenecks are, and so on.  Even better, the native code runtime
utilities are faster and run far better than similar utilities for other
languages.


Just an aside, don't fall into the trap of thinking that just because
you write code for a managed environment that you cannot have memory
leaks.  Sure, you won't have memory leaks if you're careful and free
references, but garbage collectors are all about reference counting.  If
you still hold a reachable reference to an object, but you're still
finished with it, you're going to leak memory (in that the garbage
collector won't release that memory back to the heap on your behalf).
So, code running in the CLI *can* leak, just as Vala (or C) code can
leak.


I know, I'm not assuming that. Let me elaborate. We could divide types
of leaks here:

a) Those that may occur even in a managed environment (as you
mentioned). For example subscribing to an event and forgetting to
unsubscribe it when we stop using the object.
b) Those that wouldn't occur in a managed environment, but could occur
in Vala because of the absense of a GC.
c) Those that would occur in C, but not in Vala.

So, as Gendarme is a static-analysis tool that has some rules to detect
leaks of type (a), I was assuming that it may be possible to detect
those of kind (b). I know that, for the sake of running the assembly in
Mono, the information that a Gendarme rule like this could give would be
useless, but it could be fine if someone wants to keep his source code
free of leaks in *any* environment, provided that his source code is
compilable by both environments (I mean, if what I ask above ^, marked
as "[*]", is answered with a "yes").


Gendarme is a rule checker, not a full-powered analysis tool like
valgrind.  It only knows what you tell it and it can only flag
_potential_ problems; it has no way of knowing for sure in many cases
whether the problem is _really_ there or not.  It just knows that there
is a match in its database for a code segment present in the assembly
file.

If you want to look for leaks in any system, use something like
valgrind.  That will at least give you real, helpful data.  Not sure if
Microsoft's .NET framework implementation gives out decent garbage
collection stats but if so, you can use those, as well, to determine
leaks and the like.

Revisiting whether it's possible to make the source code work in both
systems, I don't believe so.  Even with a similarly coded library
framework that provides "thought-level" compatibility between the two
systems, achieving source level compatibility isn't possible at the
moment, and probably never will be.  That simply isn't what Vala is here
to do.  If you want to write your code in C#, please, do so; Vala code
can use it with bindings to the Mono VM or similar.  C# code can call
Vala code using P/Invoke, as well.  You can integrate the two systems
together, if you choose, without terribly much difficulty---again, Vala
compiles to C, and there's two-way interoperability between managed code
there.

However, they are two different approaches to programming that
accomplish things very differently.  None of what you ask about is
impossible --- nothing is impossible.  However, trying to do things like
use a single source base for both Vala and C# would be highly
impractical, and not worth the effort.  Integrating them together using
P/Invoke or by embedding the CLI within a process written in Vala or C,
on the other hand, would be far easier, and maybe is something that
you'd be interested in looking into.

        --- Mike

-- 
Blog:  http://mike.trausch.us/blog/
Misc. Software:  http://mike.trausch.us/software/

“The greater danger for most of us lies not in setting our aim too
high and falling short; but in setting our aim too low, and achieving
our mark.” —Michelangelo
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]