jscheme-user — list for general users

[Jscheme-user] Fwd: Tim Bray, Java, Dynamic Languages, ...

[Ken A. <kan...@bb...>]

Unfortunately, JScheme and SISC seem to be below their radar screen.

This poll: http://jroller.com/page/viva/20041210
doesn't mention us either.



k
>To: Ken Anderson <kan...@bb...>
>From: Geoffrey Knauth <ge...@kn...>
>Subject: Tim Bray, Java, Dynamic Languages, ...
>Date: Mon, 13 Dec 2004 17:06:26 -0500
>X-Mailer: Apple Mail (2.619)
>X-Virus-Scanned: by amavisd-new .250  at suscom.net
>Old-X-Spam-Status: NO
>Old-X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefa=
ng)
>Old-X-Scanned-By: MIMEDefang 2.35
>X-MIME-Autoconverted: from quoted-printable to 8bit by zima.bbn.com id i=
BDM7q921723
>X-Scanned-By: Spam Assassin
>X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on zima.bbn.com
>X-Spam-Level:=20
>X-Spam-Status: No, hits=3D-4.9 required=3D5.0 tests=3DAWL,BAYES_00 autol=
earn=3Dham=20
>        version=3D2.63
>
>http://lambda-the-ultimate.org/node/view/426
>
>Tim Bray:  So on Tuesday we held a summit here at Sun, with a few of our=
 internal Java leaders, and on the dynamic-languages side, Larry Wall and=
 Dan Sugalski (Perl and Parrot), Guido van Rossum, Samuele Pedroni and Se=
an McGrath (Python), and James Strachan (Groovy). It was an educational d=
ay for us; herewith some take-aways and pictures.
>
>Everyone and his sister is linking to this blog post, so you might have =
seen it already.
>
>For a touch of flavor, here=92s just part of the list that of things to =
discuss that Larry had prepared: anonymous code/closures, lvalue methods/=
functions, variadic call/return, constant/rw/copy/ref/lazy parameters, wr=
appers/AOP, eval, exception handling/undef/nil/unthrown exceptions, excep=
tion handlers with lexical access, temporization/hypotheticality, efficie=
nt regex with complete semantics, access to dynamic context/want/caller, =
redispatch of methods (fallback upon "fail"), efficient switch statement?=
, versioned modules/classes, virtual classnames, continuations.

[Jscheme-user] Call for Participation LL4

[Ken A. <kan...@bb...>]

Call for Participation

Lightweight Languages Workshop 2004 (LL4)
=========================================
Saturday, December 4, 2004
Stata Center, MIT, Cambridge, Mass.
http://ll4.csail.mit.edu/

LL4 will be an intense, exciting, one-day forum bringing together the
best programming language implementors and researchers, from both
academia and industry, to exchange ideas and information, to challenge
one another, and to learn from one another.

If you plan to attend, please register via the website as soon as
possible.  There is no cost to attend, but we need to know how many
people to expect.  Lunch will be provided.

On-site registration will begin at 9am.  Talks will run from 10am to
5pm.  See the website for schedule details.

Talks
-----
Debugging without Programming
  Henry Lieberman, MIT Media Lab
  Earl Wagner, Northwestern University

Dynamic Languages on the Common Language Runtime (CLR) - IronPython
  Jim Hugunin, Microsoft

Using Scheme to Develop Control Systems for a Large Telescope
  Richard A. Cleis

Small programs with Zest and Marmalade
  Benjamin Schroeder and John Pierce

Eliza, a small strongly typed functional logic programming language
  Matthias Huerlemann

Continuations continued: The REST of the computation
  Anton van Straaten, AppSolutions Corp.

Gooze, a stream processing language
  Jonathan Bachrach, MIT CSAIL

Frink - A Language for Understanding the Physical World
  Alan Eliasen

Thanks
------
Sponsored by Microsoft Research
Hosted by the Software Design Group at MIT CSAIL

[Jscheme-user] tail calls in java

[Ken A. <kan...@bb...>]

Here's an interesting paper on how to do tail calls in Java.

http://docs.msdnaa.net/ark_new/Webfiles/WhitePapers/Babel01/bab12.pdf

They do a CPS conversion and rather than doing tail calls they pass in a stack depth counter with each call, when the counter goes to 0 they either throw or return a continuation.  When the original call recieves the continuation it just executes it again to keep the computation going.  

[Jscheme-user] janino embedded Java compiler.

[Ken A. <kan...@bb...>]

http://www.janino.net/

[Jscheme-user] [SISC-devel] SISC 1.9.4 Released

[Scott G. M. <sc...@sg...>]

11/22/2004: SISC 1.9.4 Released

New in this Release
-------------------

This is the first stable release in the 1.9 series.  It contains numerous
enhancements to both the engine and library. 

 * The engine now uses a flat closure representation supported by
   a referenced variable analysis pass which makes SISC "safe-for-space"
   for most programs.
 * I/O is now based on generic procedures, allowing extensibility
   from Scheme and Java.
 * Support for trapping OS signals.
 * Support for breaking evaluation at the REPL with Control-C.
 * Support for a form of primitive inlining when directed, lending
   a 2x increase in speed.
 * Added a call to retrieve the exports of a module as a list.
 * Support for the latest SRFI 45.
 * Added the "os" module, which facilitates spawning and interacting
   with external processes.
 * Immutability of sublists in quasiquote expressions now preserved.
 * Better handling of infinites and NaN values in the numeric library.
 * Serialization of Scheme values is now differential against
   loaded libraries, resulting in smaller serialized forms.
 * Better error reporting from nested loads and from the reader.
 * Numerous bug fixes.

About SISC
----------

SISC is an extensible heap-based interpreter of Scheme running on
the Java VM, with an aggressively optimized, lightweight (<200k)
Scheme engine.  SISC outperforms all existing Java
interpreters (often by more than an order of magnitude).

In addition, SISC is a complete implementation of the language.
The entire R5RS Scheme standard is supported, no exceptions.  This
includes a full number tower including complex number support,
arbitrary precision integers and floating point numbers, as well as
hygienic R5RS macros, proper tail recursion, and first-class
continuations (not just the escaping continuations as in many
limited Scheme systems).  SISC also attempts to implement the
standard as correctly as possible, while still providing
exceptional performance.

Finally, SISC provides many useful real-world extensions, such as
networking, threading, elegant exception handling, generic
procedures, an object system, SLIB and comprehensive SRFI support, a
scope-friendly module system, a Scheme and Java object system 
with a clean foreign-function interface and more.


Downloads and More Information
------------------------------

Source code, binaries, and SISC documentation can be found on 
the web at:

    http://sisc.sourceforge.net


Licensing
---------

SISC is Free Software.  It is released simultaneously under the GNU
General Public License (for free-software projects), and the Mozilla
Public License (for commercial entities).  The documentation is
available under the GPL.

-- 

Re: [Jscheme-user] JScheme Pairs

[Ken A. <kan...@bb...>]

Yes, you should subclass Pair.  THere is a jscheme.SchemePair interface but the jsint package doesn't really use it, which it should.

We should also make SchemePair extend collection.

You'll need to cast (Symbol)x.getFirst(), but won't you be just constructing lists?
I'd write some utility functions to help you.

Can you put together an example of what you're doing?  We can make it part of our documentation.

k

At 09:04 PM 11/20/2004 +0000, Peter Harman wrote:
>Hi,
> 
>A while ago I mentioned that I was using JScheme together with Antlr (<http://www.antlr.org>http://www.antlr.org). My current code is a bit of a fudge, using Antlr to generate a Scheme 'String', which I evalute. However I'm looking to generate a class extending jsint.Pair and implementing antlr.collections.AST (the Abstract Syntax Tree interface) which should make a very powerful tool for language implementation.
> 
>My question is, what does my class (call it ASTPair) need to do to convince the Scheme interpreter that it is really a 'Pair'? The main issue is, how does the Pair relate to a Symbol - as with an AST every element is of the AST class, so for the 'first()' and 'getFirst()' methods of 'Pair' would I sometimes need to cast to a 'Symbol'?
> 
>thanks
> 
>Peter
> 

[Jscheme-user] JScheme Pairs

[Peter H. <pe...@ex...>]

Hi,

A while ago I mentioned that I was using JScheme together with Antlr =
(http://www.antlr.org). My current code is a bit of a fudge, using Antlr =
to generate a Scheme 'String', which I evalute. However I'm looking to =
generate a class extending jsint.Pair and implementing =
antlr.collections.AST (the Abstract Syntax Tree interface) which should =
make a very powerful tool for language implementation.

My question is, what does my class (call it ASTPair) need to do to =
convince the Scheme interpreter that it is really a 'Pair'? The main =
issue is, how does the Pair relate to a Symbol - as with an AST every =
element is of the AST class, so for the 'first()' and 'getFirst()' =
methods of 'Pair' would I sometimes need to cast to a 'Symbol'?

thanks

Peter

[Jscheme-user] Alan's patch

[Ken A. <kan...@bb...>]

I've accepted a patch from Alan Donovan.
1 - easier embedding:

	   Evaluator eval = new Evaluator();
	   eval.setInput(...);
	   eval.setOutput(...);
	   eval.setError(...);
	   jsint.Scheme.pushEvaluator(eval);
	   jsint.Scheme.loadInit();
           eval.enableNamedResults(true);
	   eval.readEvalWriteLoop("scheme> ");

The loop returns #t if it hit EOF or #f it it was asked to exit.

2.  The value of each evaluation is kept in a variable, like $3 for the third evaluation.  This is currently on by default.

3.  I have removed the code for leadin 0 or 0x in numbers so 081 is 81, and adjusted the tests.

If (set! U.useJavaSyntax #f)
you can do #o10 and #x10 however.

[Jscheme-user] Re: patch to Jscheme

[Ken A. <kan...@bb...>]

Thanks, we sshould provid something like this.

k
At 02:12 PM 11/19/2004 -0500, Alan Donovan wrote:
>On Fri, Nov 19, 2004 at 01:12:36PM -0500, Ken Anderson wrote:
>> >Obviously, it's important that the evaluator not stop the host process
>> >by accident.  (By redefining init.scm and imposing a policy on
>> >imported Java names, you could actually enforce a secure sandbox, but
>> >I don't need this.)
>> 
>> Tell me more about how you would do the sandbox.  We have at least
>> one JScheme application in an above top secret facility, though the
>> application and data are unclassified.
>
>By a sandbox, I mean an environment where the scheme program only has
>limited access to names.  For example, if the only visible names are
>the R4RS Scheme library, minus I/O and 'exit', then the scheme program
>cannot do anything except computation: it can't stop the host process,
>read the disk, or leak information.  Typically you want to have some
>domain-specific operators available to the scheme program, so that it
>can do its job.  e.g. in an window manager, you want X11 window
>primitives; in a GUI, I want widget primitives, etc.
>
>So, all you need to do is ensure that only a subset of Java names are
>visible via the javadot notation.  For example, perhaps only names
>defined in one particular package are needed for your application.
>
>In general, however, deciding on a subset of Java names that is
>sufficient to get the job done, but not enough to break whatever
>security policy you're interested in, is a rather labor-intensive
>task.  You would have to manually inspect each class to determine
>whether it appears to be "safe" or whether it might break your
>abstraction.  You might also need to wrap some essential but unsafe
>things to provide a safe interface.
>
>It would be easy to provide an implementation though; you just need to
>allow JScheme clients to (a) filter the list of scheme primitives
>initially available in the toplevel environment, and (b) provide a
>policy object which decides which Java names are available through
>javadot notation; it would have one method:
>
>  boolean isJavaNameVisible(String name);
>
>That's the basic idea anyway.
>
>cheers
>alan

[Jscheme-user] enableNamedResults(true);

[Ken A. <kan...@bb...>]

The patch you sent me had an extension for naming the result of each read-eval-print. with say, $3.

What i've been thinking is you would also like to reevaluate a previous input expression, say with 3$.  Does that seem useful too?

Maybe
<3 - reevaluate the third expression.
>3 - the value of the third expresssion
or 
<3
3>

Re: [Jscheme-user] 081 ?bug?

[Robert J. B. <ru...@bb...>]

Tim,
I would certainly vote for this solution. To me it seems strange to 
think that the presence of a leading 0 changes the interpretation of a 
string as a number.
--Rusty


Timothy J Hickey wrote:

>
> On Nov 18, 2004, at 7:52 PM, Ken Anderson wrote:
>
>> Yes.
>>
>>> (string->number "077")
>>
>> 77
>> However, because he is a JScheme user, he  has several alternatives 
>> to choose from:
>>
>>> (string->expr "077")
>>
>> 63
>> a JScheme built in, which uses the JScheme reader.
>>
>>> (Integer. "077")
>>
>> 77
>> that uses a Java reflector.
>
>
> True....
> It seems that there is plenty of room for confusion...
> We can always use Javadot to convert from different bases...
>
>> > (Integer.parseInt "77" 8)
>> 63
>> > (Integer.parseInt "FF77" 16)
>> 65399
>> > (Long.parseLong "FF77" 16)
>> 65399L
>
>
> I suppose we could jettison the octal and hex notation for integers 
> and longs and require
> users to go to javadot if they want to use octal/hex numbers....
>
> ---Tim---
>
>
>>
>> What i'd propose now it to change the error message to be 
>> informative, something like
>> 081 is an invalid octal number.
>>
>> What really worried Rusty and i is that we need to read
>> "0770304" as 77 degrees 3 minutes and 4 seconds. to specify a 
>> latitude or longitude.  We compute these lat/lons for our customers.  
>> We do it correctly, but getting it wrong could be life threatiing.
>>
>> If nothing else we need to change the error and update the JScheme 
>> spec (where ever it is).
>>
>> Though bases other than 10 are pretty strange for our customers and 
>> users, so backing a Java thing that probably goes back to a C thing 
>> for writing device drivers, might be wrong.  There has been plenty of 
>> discussion of this feature of JScheme,  maybe it should be removed.
>>
>> k
>>
>>
>> At 07:23 PM 11/18/2004 -0500, Timothy J Hickey wrote:
>>
>>> This brings us back to an early thread from June of 2004 ...
>>> in which we decided to disallow Java octal notation in 
>>> (string->number x)
>>> invocations, but to allow it in JScheme code to ease the interaction
>>> with Java ...
>>>
>>> On Nov 18, 2004, at 6:25 PM, Robert J. Bobrow wrote:
>>>
>>>> This lef to my trying the following test:
>>>>
>>>>> (- 0777 777)
>>>>
>>>> -266
>>>
>>>
>>>> (- (string->number "0777") 777)
>>>
>>>  0
>>>
>>>> (.getClass (read))
>>>
>>> 081
>>> class jsint.Symbol
>>>
>>>> Is it required that numbers starting with 0 be treated as octal?
>>>> --Rusty
>>>>
>>>>
>>>>
>>> .
>>>
>>> The idea was that JScheme literals should be the same as Java literals
>>> whenever possible to enhance the transparency of the javadot interface.
>>> In standard Scheme code, octal is not very important because you rarely
>>> deal with 32 or 64 bit integers.  Java is a different story, e.g. 
>>> converting from
>>> long bits to double its nice to have a hex representation of 
>>> integers....
>>>
>>> ---Tim---
>>>
>>>
>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: Ken Anderson <kan...@bb...>
>>>>> Date: June 7, 2004 10:24:02 AM EDT
>>>>> To: Timothy John Hickey <tim...@ma...>
>>>>> Cc: JScheme Developers <jsc...@li...>
>>>>> Subject: Re: [Jscheme-devel] string->number
>>>>>
>>>>> So the remaining issue is what should (string->number "08") 
>>>>> return. It currently returns #f. i was hoping it would return 8.
>>>>>
>>>>> At 07:27 PM 6/6/2004 -0400, Timothy John Hickey wrote:
>>>>>
>>>>>> I've modified string->number so that in the base 10 case it 
>>>>>> allows leading zeroes...
>>>>>> The following Unit tests all pass in the current version of 
>>>>>> JScheme...
>>>>>>
>>>>>> "06/06/2004" ;; literal syntax, TJH
>>>>>>
>>>>>> ;; Default literal syntax is for Java literals,
>>>>>>
>>>>>> ;; but string->number will treat leading zeroes as decimal if 
>>>>>> base 10 is specified
>>>>>>
>>>>>> (equal? (.getClass '081) jsint.Symbol.class)
>>>>>>
>>>>>> (equal? (.getClass '0123Dig) jsint.Symbol.class)
>>>>>>
>>>>>> (equal? (.getClass '0123) java.lang.Integer.class)
>>>>>>
>>>>>> (equal? (string->number "081" 10) 81)
>>>>>>
>>>>>> (equal? (string->number "010") 10)
>>>>>>
>>>>>> (equal? (string->number "010" 8) 8)
>>>>>>
>>>>>> (equal? (tryCatch (string->number "081" 8) (lambda(e) 'error)) 
>>>>>> 'error)
>>>>>>
>>>>>> (equal? (string->number "08") #f)
>>>>>>
>>>>>> (equal? (string->number "08" 10) 8)
>>>>>>
>>>>>> (equal? (string->number "10") 8)
>>>>>>
>>>>>> (equal? (string->number "10" 10) 10)
>>>>>>
>>>>>> The implementation of string->number in the base 10 case is
>>>>>>
>>>>>>> public static Object schemeStringToNumber(String tok, int rdx) {
>>>>>>>   try { return U.toNum(Long.parseLong(tok, rdx)); }
>>>>>>>    catch (NumberFormatException e) {
>>>>>>>        try {
>>>>>>>            if (rdx!=10)
>>>>>>>                return U.FALSE;
>>>>>>>            else return new Double(tok); }
>>>>>>>        catch (NumberFormatException e2)
>>>>>>>            { return U.FALSE; }
>>>>>>>    }
>>>>>>> }
>>>>>>
>>>>>>
>>>>>> ---Tim---
>>>>>>
>>>>>>
>>>
>>>
>>> </blockquote></x-html>
>>
>>
>
>

Re: [Jscheme-user] 081 ?bug?

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

On Nov 18, 2004, at 7:52 PM, Ken Anderson wrote:

> Yes.
>> (string->number "077")
> 77
> However, because he is a JScheme user, he  has several alternatives to 
> choose from:
>
>> (string->expr "077")
> 63
> a JScheme built in, which uses the JScheme reader.
>
>> (Integer. "077")
> 77
> that uses a Java reflector.

True....
It seems that there is plenty of room for confusion...
We can always use Javadot to convert from different bases...

> > (Integer.parseInt "77" 8)
> 63
> > (Integer.parseInt "FF77" 16)
> 65399
> > (Long.parseLong "FF77" 16)
> 65399L

I suppose we could jettison the octal and hex notation for integers and 
longs and require
users to go to javadot if they want to use octal/hex numbers....

---Tim---


>
> What i'd propose now it to change the error message to be informative, 
> something like
> 081 is an invalid octal number.
>
> What really worried Rusty and i is that we need to read
> "0770304" as 77 degrees 3 minutes and 4 seconds. to specify a latitude 
> or longitude.  We compute these lat/lons for our customers.  We do it 
> correctly, but getting it wrong could be life threatiing.
>
> If nothing else we need to change the error and update the JScheme 
> spec (where ever it is).
>
> Though bases other than 10 are pretty strange for our customers and 
> users, so backing a Java thing that probably goes back to a C thing 
> for writing device drivers, might be wrong.  There has been plenty of 
> discussion of this feature of JScheme,  maybe it should be removed.
>
> k
>
>
> At 07:23 PM 11/18/2004 -0500, Timothy J Hickey wrote:
>
>> This brings us back to an early thread from June of 2004 ...
>> in which we decided to disallow Java octal notation in 
>> (string->number x)
>> invocations, but to allow it in JScheme code to ease the interaction
>> with Java ...
>>
>> On Nov 18, 2004, at 6:25 PM, Robert J. Bobrow wrote:
>>
>>> This lef to my trying the following test:
>>>> (- 0777 777)
>>> -266
>>
>>> (- (string->number "0777") 777)
>>  0
>>
>>> (.getClass (read))
>> 081
>> class jsint.Symbol
>>
>>> Is it required that numbers starting with 0 be treated as octal?
>>> --Rusty
>>>
>>>
>>>
>> .
>>
>> The idea was that JScheme literals should be the same as Java literals
>> whenever possible to enhance the transparency of the javadot 
>> interface.
>> In standard Scheme code, octal is not very important because you 
>> rarely
>> deal with 32 or 64 bit integers.  Java is a different story, e.g. 
>> converting from
>> long bits to double its nice to have a hex representation of 
>> integers....
>>
>> ---Tim---
>>
>>
>>
>>> Begin forwarded message:
>>>
>>>> From: Ken Anderson <kan...@bb...>
>>>> Date: June 7, 2004 10:24:02 AM EDT
>>>> To: Timothy John Hickey <tim...@ma...>
>>>> Cc: JScheme Developers <jsc...@li...>
>>>> Subject: Re: [Jscheme-devel] string->number
>>>>
>>>> So the remaining issue is what should (string->number "08") return. 
>>>> It currently returns #f. i was hoping it would return 8.
>>>>
>>>> At 07:27 PM 6/6/2004 -0400, Timothy John Hickey wrote:
>>>>> I've modified string->number so that in the base 10 case it allows 
>>>>> leading zeroes...
>>>>> The following Unit tests all pass in the current version of 
>>>>> JScheme...
>>>>>
>>>>> "06/06/2004" ;; literal syntax, TJH
>>>>>
>>>>> ;; Default literal syntax is for Java literals,
>>>>>
>>>>> ;; but string->number will treat leading zeroes as decimal if base 
>>>>> 10 is specified
>>>>>
>>>>> (equal? (.getClass '081) jsint.Symbol.class)
>>>>>
>>>>> (equal? (.getClass '0123Dig) jsint.Symbol.class)
>>>>>
>>>>> (equal? (.getClass '0123) java.lang.Integer.class)
>>>>>
>>>>> (equal? (string->number "081" 10) 81)
>>>>>
>>>>> (equal? (string->number "010") 10)
>>>>>
>>>>> (equal? (string->number "010" 8) 8)
>>>>>
>>>>> (equal? (tryCatch (string->number "081" 8) (lambda(e) 'error)) 
>>>>> 'error)
>>>>>
>>>>> (equal? (string->number "08") #f)
>>>>>
>>>>> (equal? (string->number "08" 10) 8)
>>>>>
>>>>> (equal? (string->number "10") 8)
>>>>>
>>>>> (equal? (string->number "10" 10) 10)
>>>>>
>>>>> The implementation of string->number in the base 10 case is
>>>>>
>>>>>> public static Object schemeStringToNumber(String tok, int rdx) {
>>>>>>   try { return U.toNum(Long.parseLong(tok, rdx)); }
>>>>>>    catch (NumberFormatException e) {
>>>>>>        try {
>>>>>>            if (rdx!=10)
>>>>>>                return U.FALSE;
>>>>>>            else return new Double(tok); }
>>>>>>        catch (NumberFormatException e2)
>>>>>>            { return U.FALSE; }
>>>>>>    }
>>>>>> }
>>>>>
>>>>> ---Tim---
>>>>>
>>>>>
>>
>>
>> </blockquote></x-html>
>

Re: [Jscheme-user] 081 ?bug?

[Ken A. <kan...@bb...>]

Yes.
> (string->number "077")
77
However, because he is a JScheme user, he  has several alternatives to choose from:

> (string->expr "077")
63
a JScheme built in, which uses the JScheme reader.

> (Integer. "077")
77
that uses a Java reflector.

What i'd propose now it to change the error message to be informative, something like
081 is an invalid octal number.

What really worried Rusty and i is that we need to read
"0770304" as 77 degrees 3 minutes and 4 seconds. to specify a latitude or longitude.  We compute these lat/lons for our customers.  We do it correctly, but getting it wrong could be life threatiing.

If nothing else we need to change the error and update the JScheme spec (where ever it is).  

Though bases other than 10 are pretty strange for our customers and users, so backing a Java thing that probably goes back to a C thing for writing device drivers, might be wrong.  There has been plenty of discussion of this feature of JScheme,  maybe it should be removed.

k


At 07:23 PM 11/18/2004 -0500, Timothy J Hickey wrote:

>This brings us back to an early thread from June of 2004 ... 
>in which we decided to disallow Java octal notation in (string->number x) 
>invocations, but to allow it in JScheme code to ease the interaction 
>with Java ... 
>
>On Nov 18, 2004, at 6:25 PM, Robert J. Bobrow wrote: 
>
>>This lef to my trying the following test: 
>>> (- 0777 777) 
>>-266 
>
>> (- (string->number "0777") 777) 
>  0 
>
>> (.getClass (read)) 
>081 
>class jsint.Symbol 
>
>>Is it required that numbers starting with 0 be treated as octal? 
>>--Rusty 
>>
>>
>>
>. 
>
>The idea was that JScheme literals should be the same as Java literals 
>whenever possible to enhance the transparency of the javadot interface. 
>In standard Scheme code, octal is not very important because you rarely 
>deal with 32 or 64 bit integers.  Java is a different story, e.g. converting from 
>long bits to double its nice to have a hex representation of integers.... 
>
>---Tim--- 
>
>
>
>>Begin forwarded message: 
>>
>>>From: Ken Anderson <kan...@bb...> 
>>>Date: June 7, 2004 10:24:02 AM EDT 
>>>To: Timothy John Hickey <tim...@ma...> 
>>>Cc: JScheme Developers <jsc...@li...> 
>>>Subject: Re: [Jscheme-devel] string->number 
>>>
>>>So the remaining issue is what should (string->number "08") return. It currently returns #f. i was hoping it would return 8. 
>>>
>>>At 07:27 PM 6/6/2004 -0400, Timothy John Hickey wrote: 
>>>>I've modified string->number so that in the base 10 case it allows leading zeroes... 
>>>>The following Unit tests all pass in the current version of JScheme... 
>>>>
>>>>"06/06/2004" ;; literal syntax, TJH 
>>>>
>>>>;; Default literal syntax is for Java literals, 
>>>>
>>>>;; but string->number will treat leading zeroes as decimal if base 10 is specified 
>>>>
>>>>(equal? (.getClass '081) jsint.Symbol.class) 
>>>>
>>>>(equal? (.getClass '0123Dig) jsint.Symbol.class) 
>>>>
>>>>(equal? (.getClass '0123) java.lang.Integer.class) 
>>>>
>>>>(equal? (string->number "081" 10) 81) 
>>>>
>>>>(equal? (string->number "010") 10) 
>>>>
>>>>(equal? (string->number "010" 8) 8) 
>>>>
>>>>(equal? (tryCatch (string->number "081" 8) (lambda(e) 'error)) 'error) 
>>>>
>>>>(equal? (string->number "08") #f) 
>>>>
>>>>(equal? (string->number "08" 10) 8) 
>>>>
>>>>(equal? (string->number "10") 8) 
>>>>
>>>>(equal? (string->number "10" 10) 10) 
>>>>
>>>>The implementation of string->number in the base 10 case is 
>>>>
>>>>>public static Object schemeStringToNumber(String tok, int rdx) { 
>>>>>   try { return U.toNum(Long.parseLong(tok, rdx)); } 
>>>>>    catch (NumberFormatException e) { 
>>>>>        try { 
>>>>>            if (rdx!=10) 
>>>>>                return U.FALSE; 
>>>>>            else return new Double(tok); } 
>>>>>        catch (NumberFormatException e2) 
>>>>>            { return U.FALSE; } 
>>>>>    } 
>>>>>} 
>>>>
>>>>---Tim--- 
>>>>
>>>>
>
>
></blockquote></x-html> 

Re: [Jscheme-user] 081 ?bug?

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

This brings us back to an early thread from June of 2004 ...
in which we decided to disallow Java octal notation in (string->number 
x)
invocations, but to allow it in JScheme code to ease the interaction
with Java ...

On Nov 18, 2004, at 6:25 PM, Robert J. Bobrow wrote:

>  This lef to my trying the following test:
>  > (- 0777 777)
>  -266
>

 > (- (string->number "0777") 777)
   0

 > (.getClass (read))
081
class jsint.Symbol

>  Is it required that numbers starting with 0 be treated as octal?
>  --Rusty
>
>
>
>
.

The idea was that JScheme literals should be the same as Java literals
whenever possible to enhance the transparency of the javadot interface.
In standard Scheme code, octal is not very important because you rarely
deal with 32 or 64 bit integers.  Java is a different story, e.g. 
converting from
long bits to double its nice to have a hex representation of 
integers....

---Tim---

>
>
> Begin forwarded message:
>
>> From: Ken Anderson <kan...@bb...>
>> Date: June 7, 2004 10:24:02 AM EDT
>> To: Timothy John Hickey <tim...@ma...>
>> Cc: JScheme Developers <jsc...@li...>
>> Subject: Re: [Jscheme-devel] string->number
>>
>> So the remaining issue is what should (string->number "08") return.  
>> It currently returns #f. i was hoping it would return 8.
>>
>> At 07:27 PM 6/6/2004 -0400, Timothy John Hickey wrote:
>>> I've modified string->number so that in the base 10 case it allows 
>>> leading zeroes...
>>> The following Unit tests all pass in the current version of 
>>> JScheme...
>>>
>>>  "06/06/2004" ;; literal syntax, TJH
>>>
>>>  ;; Default literal syntax is for Java literals,
>>>
>>>  ;; but string->number will treat leading zeroes as decimal if base 
>>> 10 is specified
>>>
>>>  (equal? (.getClass '081) jsint.Symbol.class)
>>>
>>>  (equal? (.getClass '0123Dig) jsint.Symbol.class)
>>>
>>>  (equal? (.getClass '0123) java.lang.Integer.class)
>>>
>>>  (equal? (string->number "081" 10) 81)
>>>
>>>  (equal? (string->number "010") 10)
>>>
>>>  (equal? (string->number "010" 8) 8)
>>>
>>>  (equal? (tryCatch (string->number "081" 8) (lambda(e) 'error)) 
>>> 'error)
>>>
>>>  (equal? (string->number "08") #f)
>>>
>>>  (equal? (string->number "08" 10) 8)
>>>
>>>  (equal? (string->number "10") 8)
>>>
>>>  (equal? (string->number "10" 10) 10)
>>>
>>> The implementation of string->number in the base 10 case is
>>>
>>>>  public static Object schemeStringToNumber(String tok, int rdx) {
>>>>    try { return U.toNum(Long.parseLong(tok, rdx)); }
>>>>     catch (NumberFormatException e) {
>>>>         try {
>>>>             if (rdx!=10)
>>>>                 return U.FALSE;
>>>>             else return new Double(tok); }
>>>>         catch (NumberFormatException e2)
>>>>             { return U.FALSE; }
>>>>     }
>>>>  }
>>>
>>> ---Tim---
>>>
>>>
>>>

Re: [Jscheme-user] 081 bug

[Robert J. B. <ru...@bb...>]

This lef to my trying the following test:
 > (- 0777 777)
-266

Is it required that numbers starting with 0 be treated as octal?
--Rusty



Ken Anderson wrote:

>Thanks, that helps a lot.
>
>At 03:36 PM 11/18/2004 -0500, Geoffrey Knauth wrote:
>  
>
>>On Nov 18, 2004, at 14:25, Ken Anderson wrote:
>>    
>>
>>>Rusty found this, it looks like we have another problem with numbers that start with 0.
>>>      
>>>
>>The problem appears to be with numbers starting with zero that have non-octal digits:
>>
>>JScheme 7.1 (10/16/04 5:52 AM) http://jscheme.sourceforge.net
>>    
>>
>>>01
>>>      
>>>
>>1
>>    
>>
>>>02
>>>      
>>>
>>2
>>    
>>
>>>03
>>>      
>>>
>>3
>>    
>>
>>>04
>>>      
>>>
>>4
>>    
>>
>>>05
>>>      
>>>
>>5
>>    
>>
>>>06
>>>      
>>>
>>6
>>    
>>
>>>07
>>>      
>>>
>>7
>>    
>>
>>>08
>>>      
>>>
>>SchemeException: ERROR: undefined variable "08"
>>       at jsint.E.error(E.java:14)
>>       at jsint.E.error(E.java:19)
>>       at jsint.DynamicVariable.getDynamicValue(DynamicVariable.java:27)
>>       at jsint.Evaluator.execute(Evaluator.java:345)
>>       at jsint.Evaluator.eval(Evaluator.java:272)
>>       at jsint.Evaluator.eval(Evaluator.java:261)
>>       at jsint.Evaluator.readEvalWriteLoop(Evaluator.java:120)
>>       at jsint.Evaluator.runJscheme(Evaluator.java:106)
>>       at jsint.Scheme.runJscheme(Scheme.java:169)
>>       at jsint.Scheme.defaultMain(Scheme.java:133)
>>       at jsint.Scheme.main(Scheme.java:108)
>>       at jscheme.REPL.main(REPL.java:152)
>>    
>>
>>Geoffrey
>>--
>>Geoffrey S. Knauth | http://knauth.org/gsk
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: InterSystems CACHE
>>FREE OODBMS DOWNLOAD - A multidimensional database that combines
>>robust object and relational technologies, making it a perfect match
>>for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
>>_______________________________________________
>>Jscheme-user mailing list
>>Jsc...@li...
>>https://lists.sourceforge.net/lists/listinfo/jscheme-user
>>    
>>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: InterSystems CACHE
>FREE OODBMS DOWNLOAD - A multidimensional database that combines
>robust object and relational technologies, making it a perfect match
>for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
>_______________________________________________
>Jscheme-user mailing list
>Jsc...@li...
>https://lists.sourceforge.net/lists/listinfo/jscheme-user
>
>
>  
>

Re: [Jscheme-user] 081 bug

[Ken A. <kan...@bb...>]

Thanks, that helps a lot.

At 03:36 PM 11/18/2004 -0500, Geoffrey Knauth wrote:
>On Nov 18, 2004, at 14:25, Ken Anderson wrote:
>>Rusty found this, it looks like we have another problem with numbers that start with 0.
>
>The problem appears to be with numbers starting with zero that have non-octal digits:
>
>JScheme 7.1 (10/16/04 5:52 AM) http://jscheme.sourceforge.net
>> 01
>1
>> 02
>2
>> 03
>3
>> 04
>4
>> 05
>5
>> 06
>6
>> 07
>7
>> 08
>SchemeException: ERROR: undefined variable "08"
>        at jsint.E.error(E.java:14)
>        at jsint.E.error(E.java:19)
>        at jsint.DynamicVariable.getDynamicValue(DynamicVariable.java:27)
>        at jsint.Evaluator.execute(Evaluator.java:345)
>        at jsint.Evaluator.eval(Evaluator.java:272)
>        at jsint.Evaluator.eval(Evaluator.java:261)
>        at jsint.Evaluator.readEvalWriteLoop(Evaluator.java:120)
>        at jsint.Evaluator.runJscheme(Evaluator.java:106)
>        at jsint.Scheme.runJscheme(Scheme.java:169)
>        at jsint.Scheme.defaultMain(Scheme.java:133)
>        at jsint.Scheme.main(Scheme.java:108)
>        at jscheme.REPL.main(REPL.java:152)
>>
>
>Geoffrey
>--
>Geoffrey S. Knauth | http://knauth.org/gsk
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: InterSystems CACHE
>FREE OODBMS DOWNLOAD - A multidimensional database that combines
>robust object and relational technologies, making it a perfect match
>for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
>_______________________________________________
>Jscheme-user mailing list
>Jsc...@li...
>https://lists.sourceforge.net/lists/listinfo/jscheme-user

Re: [Jscheme-user] 081 bug

[Geoffrey K. <ge...@kn...>]

On Nov 18, 2004, at 14:25, Ken Anderson wrote:
> Rusty found this, it looks like we have another problem with numbers 
> that start with 0.

The problem appears to be with numbers starting with zero that have 
non-octal digits:

JScheme 7.1 (10/16/04 5:52 AM) http://jscheme.sourceforge.net
 > 01
1
 > 02
2
 > 03
3
 > 04
4
 > 05
5
 > 06
6
 > 07
7
 > 08
SchemeException: ERROR: undefined variable "08"
	at jsint.E.error(E.java:14)
	at jsint.E.error(E.java:19)
	at jsint.DynamicVariable.getDynamicValue(DynamicVariable.java:27)
	at jsint.Evaluator.execute(Evaluator.java:345)
	at jsint.Evaluator.eval(Evaluator.java:272)
	at jsint.Evaluator.eval(Evaluator.java:261)
	at jsint.Evaluator.readEvalWriteLoop(Evaluator.java:120)
	at jsint.Evaluator.runJscheme(Evaluator.java:106)
	at jsint.Scheme.runJscheme(Scheme.java:169)
	at jsint.Scheme.defaultMain(Scheme.java:133)
	at jsint.Scheme.main(Scheme.java:108)
	at jscheme.REPL.main(REPL.java:152)
 >

Geoffrey
--
Geoffrey S. Knauth | http://knauth.org/gsk

[Jscheme-user] 081 bug

[Ken A. <kan...@bb...>]

Rusty found this, it looks like we have another problem with numbers that start with 0.

I'll take a look at it.

> 081
SchemeException: ERROR: undefined variable "081"
	at jsint.E.error(E.java:14)
	at jsint.E.error(E.java:19)
	at jsint.DynamicVariable.getDynamicValue(DynamicVariable.java:27)
	at jsint.Evaluator.execute(Evaluator.java:341)
	at jsint.Evaluator.eval(Evaluator.java:263)
	at jsint.Evaluator.eval(Evaluator.java:252)
	at jsint.Evaluator.readEvalWriteLoop(Evaluator.java:120)
	at jsint.Evaluator.runJscheme(Evaluator.java:106)
	at jsint.Scheme.runJscheme(Scheme.java:169)
	at jsint.Scheme.defaultMain(Scheme.java:133)
	at jsint.Scheme.main(Scheme.java:108)
	at jscheme.REPL.main(REPL.java:155)

[Jscheme-user] srfi 45: Primitives for Expressing Iterative Lazy Algorithms

[Ken A. <kan...@bb...>]

A while back, i was playing with lazy evaluation trying to understand monads
and ran into a stack overflow problem that surprised me.  This srfi explains it.
http://srfi.schemers.org/srfi-45/srfi-45.html

It turns out that the Ableson and Sussman book used what's called the "odd" style of lazyness which leads to problems http://mitpress.mit.edu/sicp/.  This is the style i was using.

The "even" style described in the srfi corrects the problem.  And this is what the lazy functional languages use.

k

[Jscheme-user] Marc Feeley's 90 minute Scheme to C compiler!

[Ken A. <kan...@bb...>]

http://lambda-the-ultimate.org/node/view/349

Re: [Jscheme-user] treating #null as #f in conditionals?

[Ken A. <kan...@bb...>]

Not quite, (or) is built into the evaluator.

At 06:11 PM 11/4/2004 -0500, Timothy John Hickey wrote:
>The alternative of changing the standard definition of if, cond, or, and, etc to treate #null as #f
>seems reasonable to me. If someone didn't like it they could always use a module that
>redefines them to their original meanings... 

Re: [Jscheme-user] treating #null as #f in conditionals?

[Timothy J. H. <ti...@cs...>]

On Nov 4, 2004, at 5:44 PM, Ken Anderson wrote:

> Thanks for your description of #null.  Its interesting that Scheme, 
> and functional languages can get along without it.  Why is that?  I 
> think Common Lisp had a #null called NIL.
>
> My plan was that #null and #f would be distinct objects, but that 
> #null would be treated as #f.  in conditionals.
That seems more reasonable as it just extends the semantics of some 
primitives and special forms but doesn't change
the data model of the language.
>
> The problem with Rusty and Geof's macros is you need to provide ifj, 
> andj, orj, notj, and condj.  Here's a piece of code that's written in 
> this style:
>
>        (let ((effective (.getNotamEffectiveDtg n))
>              (expire (.getNotamExpireDtg n)))
>          (if (andj effective expire)
>              (prefix " WEF " (string-append (.substring effective 2) 
> "-"
>                                             (.substring expire 2)))
>              (ifj expire (prefix " TIL " (.substring expire 2))
>                   (ifj effective (prefix " WEF " (.substring effective 
> 2)))))))
>
> which i don't like.
I agree, combining if and ifj, or and orj, etc gets too messy and 
creates new sources of error.
.
The alternative of changing the standard definition of if, cond, or, 
and, etc to treate #null as #f
seems reasonable to me. If someone didn't like it they could always use 
a module that
redefines them to their original meanings...

---Tim---

>
> treating #null like #f in conditions lets  java collections return 
> #null but let you write code like (if (member x y) ... or (if (.get 
> table key) ...
>
> k
> At 04:16 PM 11/4/2004 -0500, Alan Donovan wrote:
>> I agree; I think it's much cleaner to keep #null distinct from #f.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Jscheme-user mailing list
> Jsc...@li...
> https://lists.sourceforge.net/lists/listinfo/jscheme-user

Re: [Jscheme-user] treating #null as #f in conditionals?

[Ken A. <kan...@bb...>]

Thanks for your description of #null.  Its interesting that Scheme, and functional languages can get along without it.  Why is that?  I think Common Lisp had a #null called NIL.

My plan was that #null and #f would be distinct objects, but that #null would be treated as #f.  in conditionals.

The problem with Rusty and Geof's macros is you need to provide ifj, andj, orj, notj, and condj.  Here's a piece of code that's written in this style:

       (let ((effective (.getNotamEffectiveDtg n))
             (expire (.getNotamExpireDtg n)))
         (if (andj effective expire)
             (prefix " WEF " (string-append (.substring effective 2) "-"
                                            (.substring expire 2)))
             (ifj expire (prefix " TIL " (.substring expire 2))
                  (ifj effective (prefix " WEF " (.substring effective 2)))))))

which i don't like.

treating #null like #f in conditions lets  java collections return #null but let you write code like (if (member x y) ... or (if (.get table key) ...

k
At 04:16 PM 11/4/2004 -0500, Alan Donovan wrote:
>I agree; I think it's much cleaner to keep #null distinct from #f. 

Re: [Jscheme-user] treating #null as #f in conditionals?

[Alan D. <ado...@cs...>]

On Thu, Nov 04, 2004 at 03:55:33PM -0500, Timothy John Hickey wrote:
> One problem with identifying #f and #null is that they have
> different semantics in Java and hence would create problems when
> calling Java methods/constructors etc.

> e.g. to create a Boolean array of size 4 and store two Boolean values 
> in it, we could use
> 
>   >   (define f (list->array Boolean.class  '( #f #t #null #null)))
> 
> But if #f and #null were identified, we would not be able to represent 
> #null
> 

I agree; I think it's much cleaner to keep #null distinct from #f.

I used to think that 'null' was simply the "absence of objects", but I
have recently come to think of it as an object in its own right,
albeit a special one on which method and field accesses all throw
exceptions, and which is a subclass of everything, an "instanceof" [*]
nothing, and is equal only to itself.

Here's a somewhat tangential explanation for that statement.  I'm
working on pointer analysis: it abstracts the value of an expression
by the set of object allocation sites it can point to.  Commonly, one
represents the null pointer by the empty set; however, this is not
always a good choice.  One application of pointer analysis is to prove
that an expression cannot point to 'null', so that a region of code
can be proven free of null-pointer exceptions (so one can optimise
away dynamic null checks).  In such an analysis, it is essential to
represent the null pointer as an explicit object; then, an empty
points-to set means that an expression has no value at all, not that
it is (or may be) null.

In this view of the world, #null should satisfy exactly the same set
of string?/list?/null? predicates as does any other instance of
java.lang.Object (which according to R4RS, is none, I suppose).

alan




[*] for "instanceof", read "non-null instance of a subclass of".

Re: [Jscheme-user] treating #null as #f in conditionals?

[Timothy J. H. <ti...@cs...>]

On Nov 4, 2004, at 2:50 PM, Michael Thome wrote:

> I'm not sure I agree:  what is wrong with defining #f and #null as 
> semantically equivalent?
I would side with Rusty and Geoffrey.

One problem with identifying #f and #null is that they have different 
semantics in Java
and hence would create problems when calling Java methods/constructors 
etc.
e.g. to create a Boolean array of size 4 and store two Boolean values 
in it, we could use

   >   (define f (list->array Boolean.class  '( #f #t #null #null)))

But if #f and #null were identified, we would not be able to represent 
#null



>   Even if #null printed as #f, it might be better than the current 
> situation.
Again, it would create problems when working with the Java interface. 
You would like to know
when a Boolean function is returning #null or #f.

>  Bottom line is that #null is a projection of a non-scheme thing into 
> scheme space - it is up to jscheme to manage that projection in 
> whatever way makes the most sense.
True, but we want the Scheme space to embed into Java space as well.


>   What if we got rid of #null altogether?... or make #null a variable 
> bound to #f.
>
> cheers,
>    -mik
>
> P.S.  what bugs me is having to do (equal? foo #null):
> > (or (null? #null) (not #null))
> #f
I agree with Rusty that macros would provide a mechanism for getting 
this kind of behavior.

>
> Geoffrey Knauth wrote:
>
>> As a practical matter, it certainly seems convenient to be able to 
>> treat #null the same as #f in conditionals--I agree it is 
>> counterintuitive to have #null be not-false.
>>
>> But I'm concerned about breaking R5RS 6.3.1., "only #f counts as 
>> false in conditional expressions,"
>>
>> http://www.swiss.ai.mit.edu/~jaffer/r5rs_8.html#SEC58
>>
>> note:  (not '())  ==>  #f
>>
>> and 3.2, "no object satisfies more than one of the following 
>> predicates: boolean? pair? symbol? number? char? string? vector? 
>> port? procedure?"
>>
>> http://www.swiss.ai.mit.edu/~jaffer/r5rs_5.html#SEC20
>>
>> So we'd have to caveat the language standard, and surprise newcomers 
>> to JScheme from other Schemes.  On the principle of least surprise, 
>> we'd probably be 50-50 between surprising newcomes to JScheme from 
>> other languages vs. other Schemes.
>>
>> In Java you can't do:  Object o = NULL; if (o) { true-stuff} else { 
>> false-stuff }
>> you have to do:  if (o == NULL) ...
>> It's a pain in the butt, but it's been drilled into us.
>>
>> Reluctantly, I suggest leaving #null and the semantics of `if' alone, 
>> and offering a "new" `if', e.g., `jif', that would treat #null as #f.
>>
>> By the way, I tried to figure out what #null is in JScheme, and it 
>> isn't anything:
>>
>> > (symbol? #null)
>> #f
>> > (boolean? #null)
>> #f
>> > (pair? #null)
>> #f
>> > (vector? #null)
>> #f
>> > (procedure? #null)
>> #f
>> > (string? #null)
>> #f
>> > (port? #null)
>> (port? '#null)
>>   ====================================
>> SchemeException: ERROR: undefined variable "port?"
>> > (number? #null)
>> #f
>> > (char? #null)
>> #f
>>
>> Then I remembered that the empty list '() isn't anything either, but 
>> it also isn't #null:
>>
>> > (eq? '() #null)
>> #f
>> > (eqv? '() #null)
>> #f
>> > (equal? '() #null)
>> #f
>
> and, of course,
>
> > (null? #null)
> #f
>
> As an alternative, what about defining #f and #null as the same object?
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Jscheme-user mailing list
> Jsc...@li...
> https://lists.sourceforge.net/lists/listinfo/jscheme-user