A bug in Kawa reader

A bug in Kawa reader

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 359 bytes --]

I've noticed that if there's an escaping slash at the end of a line inside
of a string, and the new line starts with white spaces, the white spaces
will be chomped away from the resulting string - for example, assuming that
colons signify beginning of line,

:"x\
:          y"

will be read by Kawa as "xy" rather than "x          y" as it's supposed to
be.

Re: A bug in Kawa reader

[Per Bothner]

On 3/2/23 14:14, Panicz Maciej Godek via Kawa wrote:
> I've noticed that if there's an escaping slash at the end of a line inside
> of a string, and the new line starts with white spaces, the white spaces
> will be chomped away from the resulting string

That's an intended (and documented) feature.

https://www.gnu.org/software/kawa/String-literals.html#Simple-string-literals

-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: A bug in Kawa reader

[Damien Mattei]

by the way,

noone interested in making a reader that support SRFI-105 ,curly infix 
for Kawa? it should be quite easy, when i have time i prospect to do it...

i'm interested in porting my Scheme+ to kawa for JVM.

Le 02/03/2023 à 23:30, Per Bothner a écrit :
>
>
> On 3/2/23 14:14, Panicz Maciej Godek via Kawa wrote:
>> I've noticed that if there's an escaping slash at the end of a line 
>> inside
>> of a string, and the new line starts with white spaces, the white spaces
>> will be chomped away from the resulting string
>
> That's an intended (and documented) feature.
>
> https://www.gnu.org/software/kawa/String-literals.html#Simple-string-literals 
>
>

Re: A bug in Kawa reader

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 735 bytes --]

czw., 2 mar 2023 o 23:30 Per Bothner <per@bothner.com> napisał(a):

>
>
> On 3/2/23 14:14, Panicz Maciej Godek via Kawa wrote:
> > I've noticed that if there's an escaping slash at the end of a line
> inside
> > of a string, and the new line starts with white spaces, the white spaces
> > will be chomped away from the resulting string
>
> That's an intended (and documented) feature.
>
>
> https://www.gnu.org/software/kawa/String-literals.html#Simple-string-literals
>
>
You're right.
I also checked it with the spec, and it doesn't determine this behavior.

Kawa seems to behave like Gambit, Chicken and Chez in this regard,
whereas Guile and Racket behave according to my expectation.

Sorry for the noise.

Re: A bug in Kawa reader

[Sudarshan S Chawathe]

On 2023-03-03T08:45:20+0100 (Friday), Panicz Maciej Godek via Kawa writes:
> czw., 2 mar 2023 o 23:30 Per Bothner <per@bothner.com> napisa=C5=82(a):
>
> >
> >
> > On 3/2/23 14:14, Panicz Maciej Godek via Kawa wrote:
> > > I've noticed that if there's an escaping slash at the end of a line
> > inside
> > > of a string, and the new line starts with white spaces, the white space=
> s
> > > will be chomped away from the resulting string
> >
> > That's an intended (and documented) feature.
> >
> >
> > https://www.gnu.org/software/kawa/String-literals.html#Simple-string-lite=
> rals
> >
> >
> You're right.
> I also checked it with the spec, and it doesn't determine this behavior.
>
> Kawa seems to behave like Gambit, Chicken and Chez in this regard,
> whereas Guile and Racket behave according to my expectation.
>
> Sorry for the noise.

I am not sure of the spec to which you refer but R7RS Section 6.7
includes, in the itemized list of escape sequences,

  \<intraline whitespace>*<line ending>
  <intraline whitespace>* : nothing

which is the behavior you observed in Kawa, etc.

I find it to be a useful feature for fitting long strings in nicely
indented code.

Regards,

-chaw

Re: A bug in Kawa reader

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 1598 bytes --]

pt., 3 mar 2023 o 09:17 Sudarshan S Chawathe <chaw@eip10.org> napisał(a):

> On 2023-03-03T08:45:20+0100 (Friday), Panicz Maciej Godek via Kawa writes:
> > czw., 2 mar 2023 o 23:30 Per Bothner <per@bothner.com> napisa=C5=82(a):
> >
> > >
> > >
> > > On 3/2/23 14:14, Panicz Maciej Godek via Kawa wrote:
> > > > I've noticed that if there's an escaping slash at the end of a line
> > > inside
> > > > of a string, and the new line starts with white spaces, the white
> space=
> > s
> > > > will be chomped away from the resulting string
> > >
> > > That's an intended (and documented) feature.
> > >
> > >
> > >
> https://www.gnu.org/software/kawa/String-literals.html#Simple-string-lite=
> > rals
> > >
> > >
> > You're right.
> > I also checked it with the spec, and it doesn't determine this behavior.
> >
> > Kawa seems to behave like Gambit, Chicken and Chez in this regard,
> > whereas Guile and Racket behave according to my expectation.
> >
> > Sorry for the noise.
>
> I am not sure of the spec to which you refer but R7RS Section 6.7
> includes, in the itemized list of escape sequences,
>
>   \<intraline whitespace>*<line ending>
>   <intraline whitespace>* : nothing
>
> which is the behavior you observed in Kawa, etc.
>
> I checked with R5RS, which said (in section 6.3.5):

"Scheme does not specify the effect of a backslash within a string that is
not followed by a doublequote or backslash."


> I find it to be a useful feature for fitting long strings in nicely
> indented code.
>
> I've found it quite surprising, to be honest.

Re: A bug in Kawa reader

[Lassi Kortela]

> I also checked it with the spec, and it doesn't determine this behavior.
> 
> Kawa seems to behave like Gambit, Chicken and Chez in this regard,
> whereas Guile and Racket behave according to my expectation.

If you have a spare moment, a pull request to add a simple Markdown file 
about this survey to 
https://github.com/schemedoc/surveys/tree/master/surveys would be 
appreciated. (These are published at https://docs.scheme.org/surveys/.)

Re: A bug in Kawa reader

[Per Bothner]

On 3/2/23 23:08, Damien Mattei wrote:
> noone interested in making a reader that support SRFI-105 ,curly infix for Kawa? it should be quite easy, when i have time i prospect to do it...

I see little value in srfi-105.  Who would use it and why?

If you want infix notation with Scheme semantics, you
might find my "KaShell" experiment interesting:
     http://kashell.org/
(KaShell was previously called "q2".)
There are some examples/tests in gnu/q2/testsuite in the source-code.

KaShell has infix operators, with precedence - without reserved operators.
(While not implemented, a 'define-operator' would be conceptually
similar to define-syntax, but with precedence levels.)

On goal of KaShell is to be a nice language for REPL, specifially
like a "rich shell" with typed values.  That is why it avoids
needless parenteses and semi-colon-like delimiters.
Instead, KsShell uses indentation.

Large parts of the syntax I haven't decided on yet.  You can "fall back"
on using Scheme macros:
     let ((x (3 * 4))) (x + 20)
which is equivalent to Scheme:
     (let ((x (* 3 4))) (+ x 20))
but of course that is not very satisfactory.

I haven't worked on KaShell in almost 5 years, but hopefully I'll
get back to it someday.  Until then, maybe someone will be inspired.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: A bug in Kawa reader

[Damien Mattei]

i do not see any future for scheme syntax, it is too boring compared to Python,
here is a comparaison i wrote between Scheme+, an extended Scheme and Python:
https://racket.discourse.group/t/comparison-of-code-between-scheme-an-enhanced-scheme-language-and-python/2317
but it is unfortunately very slower than Python because Scheme+ is
written in Scheme. But it could be used for learning, teaching
functional programming or for programming algorithms not too much
time-critical. (I'm currently  testing it with Guile scheme to see if
it is faster or not than with Racket ,not sure at all, as Guile seems
very slower than Racket with vectors in my other codes)

I'm searching help with developers of Scheme implementations that have
the skills to integrate the features and syntax of Scheme+ at low
level in the core implementation of Scheme.
SRFI 105 Curly is needed first. I would be interested in testing a
version compiled for java byte-code to see if it is faster than with
Racket or Guile. I'm sure it should be very fast.

Damien

On Fri, Mar 3, 2023 at 6:05 PM Per Bothner <per@bothner.com> wrote:
>
> On 3/2/23 23:08, Damien Mattei wrote:
> > noone interested in making a reader that support SRFI-105 ,curly infix for Kawa? it should be quite easy, when i have time i prospect to do it...
>
> I see little value in srfi-105.  Who would use it and why?
>
> If you want infix notation with Scheme semantics, you
> might find my "KaShell" experiment interesting:
>      http://kashell.org/
> (KaShell was previously called "q2".)
> There are some examples/tests in gnu/q2/testsuite in the source-code.
>
> KaShell has infix operators, with precedence - without reserved operators.
> (While not implemented, a 'define-operator' would be conceptually
> similar to define-syntax, but with precedence levels.)
>
> On goal of KaShell is to be a nice language for REPL, specifially
> like a "rich shell" with typed values.  That is why it avoids
> needless parenteses and semi-colon-like delimiters.
> Instead, KsShell uses indentation.
>
> Large parts of the syntax I haven't decided on yet.  You can "fall back"
> on using Scheme macros:
>      let ((x (3 * 4))) (x + 20)
> which is equivalent to Scheme:
>      (let ((x (* 3 4))) (+ x 20))
> but of course that is not very satisfactory.
>
> I haven't worked on KaShell in almost 5 years, but hopefully I'll
> get back to it someday.  Until then, maybe someone will be inspired.
> --
>         --Per Bothner
> per@bothner.com   http://per.bothner.com/