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
--
_______________________________________________
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
