Re: [fonc] misc: request opinions...
Hi, for the people here in this group: what are your opinions of .NET? Its too large, too complex for what it does and I dont like its design. what of open-source alternatives, such as Mono and Portable.NET / dotGNU? They cannot keep up with .NET's versions. what of the Java VM? Too much a toy design. what about LLVM and like? It does not model the semantics of the code as well as Microsoft's Phoenix does. or, maybe, the AVM2 / Tamarin? As ECMAScript 4 is no longer what is was, Tamarin is now out on its own, as an open source version of Adobe Flash alike player. .. what of the relative merits and detractors between them? what particular features and approaches would one want to see in an ideal VM? Proper support for :- - Multiple inheritance - Proper generics/parameterized types - Algebraic datatype support - Functional support, ie tail calls and continuations - Dynamic dispatch - Multimethod dispatch - Class based Mutimethods well, I don't feel like being long (or stating my personal views as such), but if people feel like giving comments, this could be interesting... Oh, this could take quite a while Regards, Aaron ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Ocean core language
Aaron Gray [EMAIL PROTECTED] writes: Have any of you boys looked at the type systems involved to do this sort of thing ? Would you be so kind as to cite a few references so that I can understand more about these issues? I have some ideas in mind, but it would be very useful to compare and contrast them with existing work. Here's a couple on typing Smalltalk :- http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.38.4272 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.49.3121 Soft typing (citeseerx'es title is incorrect) :- http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.68.1637 Implementing compile time static typing for a runtime typed system is not that easy. But it's not that at all. I'm implementing runtime dynamic typing for a statically typed system i.e. verification, not optimization. 'for' or 'on top of ' or 'underneath' ? Or have I totally missed the point. Aaron ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Ocean core language
Hi, I'm interested to see if you can achieve the mixture of dynamism and C compatibilty within the same source language. Yes, that's a key goal I'm trying to accomplish. I guess time will tell. Hi, Have any of you boys looked at the type systems involved to do this sort of thing ? Implementing compile time static typing for a runtime typed system is not that easy. So far it looks like there are two main techneques, soft typing and gentle typing. Mixing a C typing system with multimethods or even straight dynamic dispatch is no mean feat. I have been looking into this area and it is far from simple. If anyone has any leads in this area they would be more than welcome. Regards, Aaron ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Parameterized Word Tagging: Any interest?
If this was implemented in higher-levels of abstraction we could introduce different tagging schemes to support locatives, flonums, etc. This could lead to more language features, reduced memory usage and garbage on smaller hardware and better performance on 64-bit machines that don't need the lower 3 bits of the machine word for object addresses due to alignment. Hardcoded 1-bit tags doesn't give much room for future ideas or any other immediates. I could continue the work into libid, but I haven't looked much at Jolt yet; I'm not sure where to start. Preliminary results as applied to libid here: http://kurtstephens.com/node/60 32-bit machines also don't need the lower 3 bits if you align all objects by 8 bytes. Mozilla's SpiderMonkey Javascript implementation used in Firefox and other Mozilla environments uses 3 bit tags as follows :- 000 - untagged reference to an Object 001 - a 31 bit int 010 - tagged reference to a Double 100 - tagged reference to a String 110 - tagged Boolean There is more room within the boolean's space to have thurther encoded types. The only issues are extra coing and uncoding code, which could be implicitly generated in generated code and speed issues. If its usage could be virtual and transparent in generated code (ie there or not there on a generation flag) and maybe also modifiable in instances then we would have the best of all worlds. Aaron ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] My visit to VPRI
Aaron Gray wrote: I met many of the people listed on http://vpri.org/html/people/team.html I am getting a 404 on that, try :- http://vpri.org/html/people/team.htm Aaron Works for me. Try again? The .html is producing a 404, where as the MS8.3 format leftover .htm works. Aaron ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] working on a C grammar
In my experience, parsing C is fairly easy but pre-processing real- world .c and .h files into something you can then parse is a nightmare. Its the C preprocessor macros that often make the semantics undecypherable to a machine process. Aaron ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] idc for windows platform
Hi,
Just signed onto fonc mailing list and am also in early stages of looking at MS
VC porting of idc.
Basically your going to have to do a #ifdef for the MS platforms.
you need a comma and also a __VA_ARGS__ rather than a ##ARG, something like :-
#ifndef _MSC_VER
#define _send(MSG, RCV, ARG...) ({ \
register oop _r= (RCV); \
struct __closure *_c= (struct __closure *)_libid-bind((MSG), _r); \
(_c-method)((oop)_c, _r, _r, ##ARG); \
})
#else
#define _send(MSG, RCV, ...) ({ \
register oop _r= (RCV); \
struct __closure *_c= (struct __closure *)_libid-bind((MSG), _r); \
(_c-method)((oop)_c, _r, _r, __VA_ARGS__); \
})
#endif
Watch out for wrapped lines :)
I have not tried the above as of yet but it should work.
Aaron___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] idc for windows platform
On Mon, Apr 28, 2008 at 2:18 AM, Krzysztof Kowalczyk [EMAIL PROTECTED]
wrote:
Krzysztof Kowalczyk [EMAIL PROTECTED] writes:
The other form works for both msvc and gcc (see
http://codepad.org/VxF4pBHg for a proof (well, a proof that it
compiles with gcc, or at least a version of gcc)) so the #ifdef isn't
necessary, just use __VA_ARGS__ version. I verified that it compiles
with msvc 2005.
Using __VA_ARGS__ is not quite correct with GCC. You should be able
to call the _send (or _sendv) macro without supplying any arguments
after RCV. The comma preceding __VA_ARGS__ causes a syntax error
under GCC when there are no other arguments, but if you use ##ARG it
deletes the comma and all is well.
Does MSVC compile properly without arguments?
i.e. does:
_send(abc, 123)
cause a syntax error?
Good point. MSVC handles that according to
http://msdn2.microsoft.com/en-us/library/ms177415(VS.80).aspx
and this test program, which compiles and works as expected with msvc
(and doesn't compile on gcc):
#include stdio.h
#define np(s, ...) \
printf(s, __VA_ARGS__)
int main(int argc, char **argv)
{
int d = 4;
np(hello\n);
np(s %d, d);
return 0;
}
So #ifdef is needed after all. Alternatively, all places where
_send(a,b) is used, could be changed to _send0(a,b).
Here's another possible solution if we are using C99 and have inline
functions :-
#include stdarg.h
inline oop _send( oop msg, oop rcv, ...)
{
va_list ap;
register oop _r = rcv;
struct __closure *_c;
oop ret;
va_start( ap, rcv);
_c = (struct __closure *) _libid-bind( msg, _r);
ret = (_c-method)( (oop) _c, _r, _r, ap);
va_end( ap);
return ret;
}
You will probably need a #define inline __inline for MS VC.
This is untested but should work okay. I am not at a state where I can
really test this yet, hopefully I will be able to catch up this week.
Regards,
Aaron
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] idc for windows platform
On Mon, Apr 28, 2008 at 2:48 AM, Michael FIG [EMAIL PROTECTED] wrote: Hi, Aaron Gray [EMAIL PROTECTED] writes: va_start( ap, rcv); _c = (struct __closure *) _libid-bind( msg, _r); ret = (_c-method)( (oop) _c, _r, _r, ap); va_end( ap); This changes the calling convention... the ap argument does not pass the remaining arguments on the stack, it passes a pointer to them, so they wouldn't be usable as named parameters. Ah, should have noticed that :) Oh, well have to use preprocessor then :( I think using the __VA_ARGS__ macro is best for MSVC, as per the reference Krzysztof posted. Too bad it was introduced in Visual C++ 2005... I only have access to 2003. You could use Microsoft Visual Studio Express version :- http://www.microsoft.com/express/vc/ Regards, Aaron ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
