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

["Andrés G. Aragoneses" <knocte gmail com>]

Michael B. Trausch wrote:
> On Thu, 2009-09-17 at 11:11 -0400, "Andrés G. Aragoneses" wrote:
> > Michael B. Trausch wrote:
> > > On Thu, 2009-09-17 at 11:20 +0200, Orlando José Luque Moraira wrote:
> > > > Will Vala be in the future able to compile common c# projects with the
> > > > original MS library references? (using other libraries) 
> > > Welcome to the list.
> > >
> > > It would be possible to write a similar framework library in Vala style,
> > > but there would be little point.  Any C# code would still need to be
> > > ported to use it.  Vala style is a bit different from C# style, and the
> > Hey, so I understand that a vala file may not be compilable by a C#
> > compiler, but how about the other way around? (So my question is "is
> > vala a superset of C#"?)
>
> Nope.  Again, there are not only syntax issues, but there is much more
> than the syntax that differs between what you'd see in a C# program and
> a Vala program.
>
> 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.


> 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.


> 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. [*]


> 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.


> that can be assumed to be available when writing code that targets the
> CLI.  But, if something like this _were_ to be done, to do it correctly
> and do it well, it would have to support generation of code for more
> languages than just C# or Vala:  C++ and Java, and maybe a language that
> runs on the Parrot VM, would be good ideas.  However, that's a _lot_ of
> knowledge to have to be encoded into such a system, and unless you have
> lots of time, it's likely not worth it.
>
> > > 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?


> 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).


> and valgrind for memory use profiling.  Since the output of Vala is
> (IIRC) standard C89 code, these things all will work.  Granted, you'll
> have to read through listings that have the names of the variables and
> objects in your software transformed to a normalized C form (e.g., the
> static method AllTray.Program.main becomes all_tray_program_main).  But
> you can use tools that are very mature and have been used for years in
> everyday native application and system programming.
>
> 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").


Thanks,

        Andrés

--