@sabauma so we really do want to promote the regexp and then it would be fast

@samth That’s not quite what we want to do. What we want is to associate one trace tree to each regular expression. There are probably a couple ways we could accomplish that.

1. We could allow the regexp library to expose each regexp as a green field to the JIT.

1. Duplicate the code backing the matcher for each regular expression. Since the regexp compiler is producing closures, I think we could hack procedure-specialize to do this.

trying with procedure-specialize seems worthwhile since it already exists

Yes. It would require alterations to the regexp compiler to invoke procedure-specialize on every closure corresponding to a regular expression matcher.

That seems to be the desired behaviour you would want out of the compiler though. Have the compiler specialize the matcher on each regular expression.

right, but that seems like an easy change there, rather than something complex like exposing green fields to the racket level

I agree. I don’t htink making procedure speciaze work the way we want would be too hard either.

This might actually be a good use of the constant-folding branch, actually.

@sabauma meeting?

@mflatt somehow, extraction of arbitrary racket files is failing for me with an error about finding a linklet for read

I run this:

racket -l expander/bootstrap-run -- -c compiled/cache-src ++kot read read/api.rkt ++knot read read/primitive-parameter.rkt ++knot read read/readtable-parameter.rkt ++knot read read/readtable.rkt -s -x -o x.rkt.rktl -t x.rkt

where x.rkt is just an empty file in #lang racket/base

and it produces this error:

hash-ref: no value found for key
  key: '#s(link #<path:/home/samth/tmp/linklet/pkgs/expander/read/readtable.rkt> 0)
  context...:
   /home/samth/tmp/linklet/pkgs/expander/extract/flatten.rkt:163:0: find-knot-tying-alternate
   /home/samth/tmp/linklet/pkgs/expander/extract/flatten.rkt:92:6: for-loop
   /home/samth/tmp/linklet/pkgs/expander/extract/flatten.rkt:90:4: for-loop
   /home/samth/tmp/linklet/pkgs/expander/extract/flatten.rkt:65:2: for-loop
   /home/samth/tmp/linklet/pkgs/expander/extract/flatten.rkt:55:0: pick-variable-names21
   /home/samth/tmp/linklet/pkgs/expander/extract/flatten.rkt:13:0: flatten!12
   /home/samth/tmp/linklet/pkgs/expander/extract/main.rkt:23:0: extract11
   "/home/samth/tmp/linklet/pkgs/expander/run.rkt": [running body]
   for-loop_82
   run-module-instance!123.1
   for-loop_81
   for-loop_80
   run-module-instance!123.1
   perform-require!74.1

but extracting the expander works fine (just delete -t x.rkt)

similarly, extracting a small file that uses #%kernel also works

@samth use ++knot read -- insead of the other ++knots

I will eventually change the extraction code to delay the complaints until the reference survives simplification, and ++not read -- shouldn’t be needed after that

The ++knots for the expander don’t work because your module doesn’t implement the reader

@mflatt I think I’m missing something

because that doesn’t work — it complains about being unable to find --.rkt

I think it should be - instead of --

great, that works

I’m getting closer to automatically running a racket file via chez

still some import stuff to get working