public inbox for kawa@sourceware.org
 help / color / mirror / Atom feed
* Kawa evaluation process
@ 2022-06-28  4:54 Panicz Maciej Godek
  2022-06-28  5:19 ` Per Bothner
  0 siblings, 1 reply; 3+ messages in thread
From: Panicz Maciej Godek @ 2022-06-28  4:54 UTC (permalink / raw)
  To: kawa

Hi,

as I mentioned before, I'm working on a structure editor for Scheme.
One challange that I've been facing is to represent atoms (other than
vectors and strings).

The problem with atoms, though, is that they can be of different types -
for example, the atom represented by "x" is a symbol, but if I add the
character ":" at the end, it becomes a keyword. Or the atom represented by
"1" is  an exact number, but if I add some non-numeric character, it
becomes something else.

Moreover, some values have more than one print representation - for
example, number 1 can be represented as "1", "#x1", "#o1" etc.

So I've been wondering if there's an option to create a "box" that would be
transparent to the process of evaluation (possibly with some tweaks to
Kawa): that I would have an object that holds a string and a value, and
when the evaluator asks it for the value, it would provide whatever value
would result from parsing the string?

(my current "solution" to this problem is that I only support symbols, but
my project reached the stage where this is no longer an option)

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Kawa evaluation process
  2022-06-28  4:54 Kawa evaluation process Panicz Maciej Godek
@ 2022-06-28  5:19 ` Per Bothner
  2022-06-28  6:17   ` Panicz Maciej Godek
  0 siblings, 1 reply; 3+ messages in thread
From: Per Bothner @ 2022-06-28  5:19 UTC (permalink / raw)
  To: kawa



On 6/27/22 21:54, Panicz Maciej Godek via Kawa wrote:
> So I've been wondering if there's an option to create a "box" that would be
> transparent to the process of evaluation (possibly with some tweaks to
> Kawa): that I would have an object that holds a string and a value, and
> when the evaluator asks it for the value, it would provide whatever value
> would result from parsing the string?

Wel, we mostly have that.  Every atom (almost - see below) appears as the
car of a cons cell in a list.  So we can associate extra information with
the Pair.  Since Pair is a class you can inherit from, you can create
subclass of Pair with extra information.  This is how line number information
is handled in Kawa - see the PairWithPosition class.

Note a PairWithPosition can specify a range in a sourcefile, which gives you
the actual source string for the atom.  The comments in the file hint at
generalizing the filename/position pair to use a general gnu.text.SourceMapper.
Or you can you can create new subclasses of PairWithPosition.

There are some limitations to the atom/car-of-Pair identity.  One is
in the case of an impure list (dotted pair) - which isn't valid in source code
anyway except inside quotes.  Another limitation is for atoms that are top-level forms.
Kawa handles that by wrapping such an atom in a fake begin list - see
gnu/kawa/lispexpr/LispReader.java line 503.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Kawa evaluation process
  2022-06-28  5:19 ` Per Bothner
@ 2022-06-28  6:17   ` Panicz Maciej Godek
  0 siblings, 0 replies; 3+ messages in thread
From: Panicz Maciej Godek @ 2022-06-28  6:17 UTC (permalink / raw)
  To: Per Bothner; +Cc: kawa

Thanks for the quick response!

wt., 28 cze 2022 o 07:20 Per Bothner <per@bothner.com> napisał(a):

>
>
> On 6/27/22 21:54, Panicz Maciej Godek via Kawa wrote:
> > So I've been wondering if there's an option to create a "box" that would
> be
> > transparent to the process of evaluation (possibly with some tweaks to
> > Kawa): that I would have an object that holds a string and a value, and
> > when the evaluator asks it for the value, it would provide whatever value
> > would result from parsing the string?
>
> Wel, we mostly have that.  Every atom (almost - see below) appears as the
> car of a cons cell in a list.  So we can associate extra information with
> the Pair.  Since Pair is a class you can inherit from, you can create
> subclass of Pair with extra information.


This sounds great!
Actually, I already have a subclass of Pair (because Kawa pairs failed to
work with Java's weak hash tables, because of their identity function):

https://github.com/panicz/grasp-android/blob/master/stages/retreat/GRASP/src/primitive.scm#L33

so what I think I can do is override the getCar and getCdr methods, so that
- if the item held by them is an atom - they would return that atom's
value. (I think it makes sense)



> This is how line number information
> is handled in Kawa - see the PairWithPosition class.
>
> Note a PairWithPosition can specify a range in a sourcefile, which gives
> you
> the actual source string for the atom.  The comments in the file hint at
> generalizing the filename/position pair to use a general
> gnu.text.SourceMapper.
> Or you can you can create new subclasses of PairWithPosition.
>
>
That's good to know.
I actually haven't been using PairWithPosition (or subclassing, for that
matter).
Instead, I've been using weak-key hash tables representing spaces before
head, after head,
before (dotted) tail and after tail, and some other properties:
https://github.com/panicz/grasp-android/blob/master/stages/retreat/GRASP/src/space.scm#L370

I guess that subclassing would result in more efficient code (but I don't
know if I'd be able to change it quickly at this point)

I also wrote my own parser that uses this representation
https://github.com/panicz/grasp-android/blob/master/stages/retreat/GRASP/src/parse.scm

but I wonder if I could somehow piggyback on your parser to parse atoms?
(I mean something like (call-with-input-string <input> read), but perhaps a
bit more low-level,
because at that point we already know that the thing we're reading isn't a
list)


There are some limitations to the atom/car-of-Pair identity.  One is
> in the case of an impure list (dotted pair) - which isn't valid in source
> code
> anyway except inside quotes.  Another limitation is for atoms that are
> top-level forms.
> Kawa handles that by wrapping such an atom in a fake begin list - see
> gnu/kawa/lispexpr/LispReader.java line 503.
> --
>         --Per Bothner
> per@bothner.com   http://per.bothner.com/
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-06-28  6:17 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-28  4:54 Kawa evaluation process Panicz Maciej Godek
2022-06-28  5:19 ` Per Bothner
2022-06-28  6:17   ` Panicz Maciej Godek

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).