Re: unrecognized syntax: type[args]

[Damien Mattei <damien.mattei@gmail.com>]

and anyway,in scheme+ , in future all the SRFI-105 converter to scheme
will be done outside the scheme implementation ,even if there exist
already a srfi-105 implementation for a particular scheme because the
optimisation must be done before compilation the process will be:

curly-infix-neoteric -> scheme prefix -> optimiser for $bracket-apply$
,$nfx$,... -> scheme compiler (kawa,racket,guile,bigloo....)

and this solve the problem of the scheme implementation that rarely
implement SRFI105

note that the optimiser i'm currently writing is in scheme and as it
is external i can write it any scheme, Kawa for example or racket or
guile , and use it with another scheme+ implementation (guile or
racket)

On Sun, Oct 8, 2023 at 11:02 AM Damien Mattei <damien.mattei@gmail.com> wrote:
>
> nothing is perfect but i have a solution,i do not know all the non
> R*RS syntax special features of kawa, i will assume type[] will have
> to be replaced in a program in Kawa by ($bracket-apply$ type) to use
> this feature, also a vector as [1 2 3] should be written #(1 2 3) .
> This is not a big deal. Because my curly-infix2prefix parser can not
> deal with those syntax, they conflict with SRFI 105.
> After in my code i need to replace $bracket-apply$ that is already use
> in Kawa by bracket-apply for example (also in my code $bracket-apply$
> is a procedure and it is incompatible with type that must not be
> evaluated as argument and i do not want to go back when
> $bracket-apply$ was a macro in my code). Those modifications will not
> touch the Kawa source code ,only my code and still preserve SRFI 105
> features and i hope all Kawa special syntax features as my
> reader-parser is external to Kawa.(i also writing an optimiser that
> act before the code is pass to the scheme compiler as Scheme+ create a
> lot of slow down that can be  optimize before, especially infix with
> precedence parsing could be done before compilation and not at runtime
> but this is not special to kawa but to all scheme implementation of
> scheme+)
>
> On Sun, Oct 8, 2023 at 10:11 AM Damien Mattei <damien.mattei@gmail.com> wrote:
> >
> > it is hard to modify without touching or breaking deeply the kawa code
> > or my code because $bracket-apply$ is coded in java in
> > BracketApply.java
> > do you know a way to rename $bracket-apply$ it. The standart scheme
> > way i know does not work, the cause seems to be that it is java behind
> > , it is not a macro ,not a procedure:
> > #|kawa:9|# $bracket-apply$
> > #<syntax <unnamed>>
> > i ideally want to rewrite $bracket-apply$ and be able to reuse in it
> > the code of the previous definition of $bracket-apply$....
> >
> > first problem is to rename this "object" $bracket-apply$ in kawa ?
> >
> > On Sat, Oct 7, 2023 at 6:59 PM Damien Mattei <damien.mattei@gmail.com> wrote:
> > >
> > > yes it is what i was understanding and verifying:
> > >
> > > https://www.gnu.org/software/kawa/tutorial/Types.html
> > >
> > >
> > > |kawa:21|# (define x (int[] 1 2 3))
> > > #|kawa:22|# x
> > > [1 2 3]
> > >
> > > i discover that:
> > > #|kawa:23|# (define x (($bracket-apply$ int) 1 2 3))
> > > #|kawa:24|# x
> > > [1 2 3]
> > >
> > > yes i can redefining , that was in my code , but it fails, probably
> > > one of my definition used it before redefinition , i will test that
> > > and in the worse case use another keyword than  $bracket-apply$ when
> > > curly-infix2prefix.scm parse the [ ] and convert it in prefix....
> > >
> > > On Sat, Oct 7, 2023 at 6:42 PM Per Bothner <per@bothner.com> wrote:
> > > >
> > > > In Kawa $bracked-apply$ is a pre-defined macro - but it is not hard-wired.
> > > > You can re-bind it to something else.  You probably should.
> > > > Either that, or change the reader to conervt foo[args] to something different.
> > > > --
> > > >         --Per Bothner
> > > > per@bothner.com   http://per.bothner.com/