The 1.1 DotLisp.dll seems to work fine when forced to load in v2.0 (as did a 1.0 build in 1.1), including working with generic types. (However, there's a couple of types that need their namespace explicitly defined in boot.lisp and my extra.lisp.*)
Recompiling my patched version is also successful (except for warnings about removing the assembly attributes regarding the keyfile and container).
Nevertheless, to try supporting generic types slightly more, I've changed the 'declaration' of the ReadBackQuote ReaderMacro to isTerminating=false (in Reader.cs:Reader.ctor).
(This means existing code with no whitespace between a symbol and ` will break; eg. (list`(~x)) needs a space inserted after list. I've found this to be rarely needed in my existing code, as ` is normally the first non-whitespace on a line.)
I have also changed the type creation code (in Util.cs:Util.InvokeObject) so that (SomeGenericTypeDefinition. T1. T2. ...) creates the type SomeGenericTypeDefinition<T1,T2> (by calling Type:MakeGenericType).
which returns an object of type List`1<String> in the unchanged code (using my extra.lisp's T typize macro), can be expressed as:
((List`1. String.))
Similarly a calendar type could be defined using:
(set Calendar (Dictionary`2. DateTime. String.))
If I don't find any problems with this in the next week or two, I'll offer it as a patch.
(*) There are getting to be enough important types that need to be fully specified, we need to consider ways of implementing namespace resolution priorities.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been busy on other things, but there's only two changes for (simple) Generic Type support:
'Declare' the ` ReaderMacro have isTerminating false; and
add a test for GenericTypeDefinition when testing a Type as the first form in an s-expression.
The only other v2 change is the suggestion not to include key signing in the code but in the command line. I've made that change to get back to 0 warnings.
boot.lisp and extra.lisp are included, with comments at the top regarding the extra types that need their namespaces made explicit. I also expanded my type-info routine to display Generics information.
[I've started to look at supporting Generic Methods, in extra.lisp, but it's a little convoluted at the moment.]
In other words, this is still a work in progress...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have posted a patch with my current version of DotLisp, still targeting .NET 3.5/2.0 but mostly using it in 4+, on Windows 10 (with an exe.config forcing it to use/know that).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The 1.1 DotLisp.dll seems to work fine when forced to load in v2.0 (as did a 1.0 build in 1.1), including working with generic types. (However, there's a couple of types that need their namespace explicitly defined in boot.lisp and my extra.lisp.*)
Recompiling my patched version is also successful (except for warnings about removing the assembly attributes regarding the keyfile and container).
Nevertheless, to try supporting generic types slightly more, I've changed the 'declaration' of the ReadBackQuote ReaderMacro to isTerminating=false (in Reader.cs:Reader.ctor).
(This means existing code with no whitespace between a symbol and ` will break; eg. (list`(~x)) needs a space inserted after list. I've found this to be rarely needed in my existing code, as ` is normally the first non-whitespace on a line.)
I have also changed the type creation code (in Util.cs:Util.InvokeObject) so that (SomeGenericTypeDefinition. T1. T2. ...) creates the type SomeGenericTypeDefinition<T1,T2> (by calling Type:MakeGenericType).
The two of these changes combined means
((.MakeGenericType (T"System.Collections.Generic.List'1") [String.]))
which returns an object of type List`1<String> in the unchanged code (using my extra.lisp's T typize macro), can be expressed as:
((List`1. String.))
Similarly a calendar type could be defined using:
(set Calendar (Dictionary`2. DateTime. String.))
If I don't find any problems with this in the next week or two, I'll offer it as a patch.
(*) There are getting to be enough important types that need to be fully specified, we need to consider ways of implementing namespace resolution priorities.
Hi Mark,
I'd like to try DotLisp on .NET 2.0. Would it be possible to post your patch?
Thanks,
Wayne Vucenic
I've been busy on other things, but there's only two changes for (simple) Generic Type support:
'Declare' the ` ReaderMacro have isTerminating false; and
add a test for GenericTypeDefinition when testing a Type as the first form in an s-expression.
The only other v2 change is the suggestion not to include key signing in the code but in the command line. I've made that change to get back to 0 warnings.
See http://www.ozemail.com.au/~markhurd/dotlisp-v2patch.zip
boot.lisp and extra.lisp are included, with comments at the top regarding the extra types that need their namespaces made explicit. I also expanded my type-info routine to display Generics information.
[I've started to look at supporting Generic Methods, in extra.lisp, but it's a little convoluted at the moment.]
In other words, this is still a work in progress...
I have posted a patch with my current version of DotLisp, still targeting .NET 3.5/2.0 but mostly using it in 4+, on Windows 10 (with an exe.config forcing it to use/know that).