jscheme-devel

[Jscheme-devel] feature request: strict-import

[Kyle R. B. <kyl...@gm...>]

The current import function is lazy, which nice from an interactive point of
view.  From knowing that the code will execute point of view, it is less
desirable.  I'd like to propose an additional function: strict-import that
would error if the class being imported is not actually found at the time
the strict-import is processed.

I can think of a few ways that strict-import could behave:

  (strict-import class-name)

In addition to calling Import.addImport, this would also validate that the
class can actually be loaded, otherwise it would throw an exception (class
not found exception).

  (strict-import "class.or.package.name.*")

If the arg prefix (dropping the wildcard) is a package name, then this works
exactly as the existing import (no detectable errors).  if the arg prefix is
a class name, then all the static methods in the class are imported as
symbols in the current environment:

  (strict-import "java.lang.Math.*")

Would create a function 'random in the current environment.

  (strict-import "java.lang.Math.random")

In this case the form is requesting the importing of a single static method
from the Math class, it would create a function 'random in the current
environment.


I can work at creating an example implementation some night this week (I
don't expect it to be difficult) if it is warranted.

We're using JScheme in one of our production applications (for a DSL) and
we're looking to have it be as strict as possible so that we end up
deferring as few errors/issues to runtime as possible.  Detecting failed
class imports (when the class is not actually on the classpath) would help
towards this goal.


Also, I've noticed that the implementation uses Vector and Hashtable quite a
bit.  I realize that they were what was available when JScheme was created
and the newer (and generally considered better) ArrayList and HashMap were
not available until java 1.2.  Is there any reason at this point not to
switch the code to use the newer collections framework?  There may be a
performance difference since ArrayList and HashMap are not synchronized
themselves - and it looks like the code in JScheme is doing a lot of the
synchronization itself anyway.


Thanks,

Kyle

Re: [Jscheme-devel] feature request: strict-import

[Timothy J H. <tjh...@br...>]

On Sep 24, 2007, at 4:49 PM, Kyle R. Burton wrote:

> The current import function is lazy, which nice from an interactive  
> point of view.  From knowing that the code will execute point of  
> view, it is less desirable.  I'd like to propose an additional  
> function: strict-import that would error if the class being  
> imported is not actually found at the time the strict-import is  
> processed.
That sounds reasonable and not too hard to implement.
>
>
> I can think of a few ways that strict-import could behave:
>
>   (strict-import class-name)
>
> In addition to calling Import.addImport, this would also validate  
> that the class can actually be loaded, otherwise it would throw an  
> exception (class not found exception).
>
>   (strict-import "class.or.package.name.*")
>
> If the arg prefix (dropping the wildcard) is a package name, then  
> this works exactly as the existing import (no detectable errors).   
> if the arg prefix is a class name, then all the static methods in  
> the class are imported as symbols in the current environment:
>
>   (strict-import "java.lang.Math.*")
This is something we would need to discuss.
The nice thing about the javadot notation is that you can tell by  
looking at a procedure name if it is a Java element
and if one follows the convention of not using "." in any user- 
defined scheme names, then it separates those name
spaces syntactically.

If we break that naming convention one could import a Java class that  
contains a static method "car" which could
reek havoc with any scheme code ...

Another approach would be to specify which static methods should be  
imported without the "." notation, e.g.
      (string-import "java.lang.Math" '(random ulp IEEEremainder))

>
>
> Would create a function 'random in the current environment.
>
>   (strict-import "java.lang.Math.random")
>
> In this case the form is requesting the importing of a single  
> static method from the Math class, it would create a function  
> 'random in the current environment.
>
>
> I can work at creating an example implementation some night this  
> week (I don't expect it to be difficult) if it is warranted.
>
> We're using JScheme in one of our production applications (for a  
> DSL) and we're looking to have it be as strict as possible so that  
> we end up deferring as few errors/issues to runtime as possible.   
> Detecting failed class imports (when the class is not actually on  
> the classpath) would help towards this goal.
Adding some error checking sounds like a good idea to me..
>
>
>
> Also, I've noticed that the implementation uses Vector and  
> Hashtable quite a bit.  I realize that they were what was available  
> when JScheme was created and the newer (and generally considered  
> better) ArrayList and HashMap were not available until java 1.2.   
> Is there any reason at this point not to switch the code to use the  
> newer collections framework?  There may be a performance difference  
> since ArrayList and HashMap are not synchronized themselves - and  
> it looks like the code in JScheme is doing a lot of the  
> synchronization itself anyway.
This is a very interesting idea.
A more ambitious project would be to rewrite the JScheme codebase  
using the newer collections and generics.
If there is enough interest we could start work on this and take the  
opportunity to clean up the code and javadoc
comments throughout....

Best,
---Tim---

Re: [Jscheme-devel] feature request: strict-import

[Timothy J H. <tjh...@br...>]

On Sep 24, 2007, at 5:37 PM, Geoff Knauth wrote:

> I can't think of a more appropriate list!
>
> strict-import sounds like a reasonable feature.  The only thing I  
> don't like about it is users having to change their imports into  
> strict-imports.  Users might get paranoid that "import" is no  
> longer good enough, so then they'd be typing the longer version all  
> the time.  I wonder if it would be possible to do something like  
> (strict-imports boolean) so that people wouldn't have to change  
> their code, only the current loading behavior.
We could probably just change the implementation of import so that it  
signals an error if the class is not found.
This might temporarily break some old code, but only if it were  
important classes that didn't exist, in which
case the imports could be taken out or enclosed in a trycatch  
expression.

---Tim---

>
> Further comments below.
>
> On Sep 24, 2007, at 16:54, Kyle R. Burton wrote:
>
>> Is jscheme-devel the appropriate list?  I received a message  
>> indicating that the message is awaiting moderator approval.   
>> Should I just be using jscheme-users?
>>
>> Thanks,
>>
>> Kyle
>>
>> ---------- Forwarded message ----------
>> From: Kyle R. Burton <kyl...@gm...>
>> Date: Sep 24, 2007 4:49 PM
>> Subject: feature request: strict-import
>> To: jsc...@li...
>>
>> The current import function is lazy, which nice from an  
>> interactive point of view.  From knowing that the code will  
>> execute point of view, it is less desirable.  I'd like to propose  
>> an additional function: strict-import that would error if the  
>> class being imported is not actually found at the time the strict- 
>> import is processed.
>>
>> I can think of a few ways that strict-import could behave:
>>
>>   (strict-import class-name)
>>
>> In addition to calling Import.addImport, this would also validate  
>> that the class can actually be loaded, otherwise it would throw an  
>> exception (class not found exception).
>>
>>   (strict-import "class.or.package.name.*")
>>
>> If the arg prefix (dropping the wildcard) is a package name, then  
>> this works exactly as the existing import (no detectable errors).   
>> if the arg prefix is a class name, then all the static methods in  
>> the class are imported as symbols in the current environment:
>>
>>   (strict-import "java.lang.Math.*")
>>
>> Would create a function 'random in the current environment.
>>
>>   (strict-import "java.lang.Math.random")
>>
>> In this case the form is requesting the importing of a single  
>> static method from the Math class, it would create a function  
>> 'random in the current environment.
>>
>>
>> I can work at creating an example implementation some night this  
>> week (I don't expect it to be difficult) if it is warranted.
>>
>> We're using JScheme in one of our production applications (for a  
>> DSL) and we're looking to have it be as strict as possible so that  
>> we end up deferring as few errors/issues to runtime as possible.   
>> Detecting failed class imports (when the class is not actually on  
>> the classpath) would help towards this goal.
>
> I like that argument.  I could have used it in previous battles  
> discussions with management in years past.
>
>> Also, I've noticed that the implementation uses Vector and  
>> Hashtable quite a bit.  I realize that they were what was  
>> available when JScheme was created and the newer (and generally  
>> considered better) ArrayList and HashMap were not available until  
>> java 1.2.  Is there any reason at this point not to switch the  
>> code to use the newer collections framework?
>
> I wonder if anyone is still using JVMs prior to 1.2?  I guess they  
> could still use "old" JScheme.
>
>> There may be a performance difference since ArrayList and HashMap  
>> are not synchronized themselves - and it looks like the code in  
>> JScheme is doing a lot of the synchronization itself anyway.
>
> We can run tests!

Re: [Jscheme-devel] feature request: strict-import

[Kyle R. B. <kyl...@gm...>]

> strict-import sounds like a reasonable feature.  The only thing I
> don't like about it is users having to change their imports into
> strict-imports.  Users might get paranoid that "import" is no longer
> good enough, so then they'd be typing the longer version all the
> time.  I wonder if it would be possible to do something like (strict-
> imports boolean) so that people wouldn't have to change their code,
> only the current loading behavior.


I actually prefer the strict-imports form you're suggesting.  It would have
to modify the interpreter instance or set a global correct?  Adding the
strict import at the top of a module/file would be nice since it would
effectively be a declaration.  Would it just have file/module scope or in
the entire interpreter?  I'm not sure what the best way would be to
implement this in the current code base.

Further comments below.
>
> > We're using JScheme in one of our production applications (for a
> > DSL) and we're looking to have it be as strict as possible so that
> > we end up deferring as few errors/issues to runtime as possible.
> > Detecting failed class imports (when the class is not actually on
> > the classpath) would help towards this goal.
>
> I like that argument.  I could have used it in previous battles
> discussions with management in years past.


There are probably a lot of features that could be added to help in this
respect (especially if they were optional, as suggested above).  I actually
would have pushed to use JScheme more if it weren't for the issue of lack of
confidence in the runtime code.  Unit testing helps but only goes so far.

I wonder if anyone is still using JVMs prior to 1.2?  I guess they
> could still use "old" JScheme.



> There may be a performance difference since ArrayList and HashMap
> > are not synchronized themselves - and it looks like the code in
> > JScheme is doing a lot of the synchronization itself anyway.
>
> We can run tests!


Since you brought that up, what is the opinion on testing during the build?
I see that tests are run, but they do not cause the build to fail as far as
I can tell.  Also, what would the opinion be on using JUnit as a testing
framework?  Or even one of the common Java build tools like Maven?

We use Maven and the dependency declarations are very valuable - also, it
would have been nice if JScheme were part of the ibiblio maven repository it
could be used from maven projects (and thus automatically downloaded).



Kyle