Archived messages from: gitter.im/red/red.js from year: 2020

ALANVF
22:11Red.js repo: https://github.com/ALANVF/Red.js
22:13Red.js interactive REPL link: https://redjs-compiled-repl.theangryepicbanana.repl.run
22:15I feel like something else should be here, but I can't figure out what...
GiuseppeChillemi
22:29I am here, Waiting to see your progress!
ALANVF
22:30:thumbsup:
GaryMiller
23:40Very Exciting! Also exciting there are a few talented people working on getting a cross platform TypeScript compiler and others a TypeScript to C transpiler which would allow you to compile your TypeScript Red to a .exe https://deepu.tech/deno-runtime-for-typescript/ Since MicroSoft's .Net Core is crossplatform now it could be quicker path to 64 bits.
ALANVF
23:40ah nice :thumbsup:
23:41can't wait for 64 bits!
23:42for now, I think that you could compile Red.js to WebAssembly and then turn that into an executable maybe?

ALANVF
00:39Feature progress is now documented here: https://github.com/ALANVF/Red.js/blob/master/FEATURES.md
greggirwin
01:34Great chart! B = Just broken. :^)
ALANVF
01:35thanks (yes lol)
01:35thought that summed it up pretty well
GiuseppeChillemi
06:19Yes, great chart, I have liked it a lot!
meijeru
08:39The charts are great, and show your thoroughness. I am waiting with interest for your chart on actions.
planetsizecpu
09:44Great stuff @ALANVF push hard!
endo64
11:31Great work @ALANVF !
pekr
11:38It would be nice if the help would somehow work? That might be the first thing ppl might try in a console?
ALANVF
15:35ah yea, I'll try adding that soon @pekr :thumbsup:
15:36thank you @planetsizecpu and @endo64 :)
meijeru
17:10@ALANVF I have an up-to-date table of actions vs types, with inheritance indicated. Are you interested, if only for completeness check?
ALANVF
17:11Definitely!
17:12that would be very helpful
meijeru
17:17I will send it to you by e-mail. Meanwhile, this is a bug, I think:
> tail? []
RawLogic { cond: false }

ALANVF
17:18oh nice, thanks!
17:18will fix
meijeru
17:20What e-mail address can I use for you?
ALANVF
17:22theangryepicbanana@gmail.com should be good :thumbsup:
17:44[![image.png](https://files.gitter.im/red/red.js/Ll96/thumb/image.png)](https://files.gitter.im/red/red.js/Ll96/image.png)
17:44fixed
hiiamboris
18:07At some point you might want to run parts of the [Red test suite](https://github.com/red/red/tree/master/tests) to become confident in the interpreter's quality
ALANVF
18:08Ah yeah probably
18:10I'll probably try doing that once I add more natives and actions
18:35[![image.png](https://files.gitter.im/red/red.js/dhyP/thumb/image.png)](https://files.gitter.im/red/red.js/dhyP/image.png)
18:36it's not complete (due to most datatypes not having actions) but it works
20:02New update for version 0.0.5:
- Added case native.
- Added basic actions for datatype!.
- Fixed bug where tail? [] would return false.
- Added basic actions for path!, lit-path!, set-path!, and get-path!.
- Added an interactive help function (although it's fairly incomplete).
- Added some of the built-in helper functions.
- Error messages related to missing type actions are now more descriptive.
20:04The [Red.js REPL](https://redjs-compiled-repl.theangryepicbanana.repl.run) has also been updated to version 0.0.5
hiiamboris
20:08:+1:

Respectech
02:04Is it possible to control the DOM using Red.js?
hiiamboris
07:56It's in the TODO.md ;)
GaryMiller
10:57I don't think DOM control is possible in Web Assembly directly yet though. So you may have to choose betweenn DOM and speed if transpiling to Web Assembly is a lot faster. But the following article seems to state that it's not under some circumstances.

Rossberg said that WASM is really just this sandboxed virtual instruction set. It doesn't have any capabilities in itself. But one of the first questions you get is, how do I access the DOM? The answer is you can't directly, you have to go through JavaScript, and that's by design.

https://www.theregister.co.uk/2020/01/17/webassembly_key_to_a_highperformance_web_or_ideal_for_malware/
hiiamboris
12:21Interesting that this room also gets the full commit activity on the right. If anything it should receive the activity from Red.js repo
12:22I wonder if there's a mask like /red/red* that pushes it here
12:25@x8x would you happen to know anything about this?
greggirwin
15:54I entered the red.js repo name when setting it up, but it seems Gitter doesn't use that because it's not under the Red organization on github. My best guess anyway.
ALANVF
15:54Yeah I noticed that
15:55maybe put the repo link in the description for now?
greggirwin
15:57Done.
ALANVF
15:57:thumbsup:
meijeru
16:52A suggestion to add one tiny feature to help: if the user types it without an argument (which is what many users will do first, I suppose), answer with a short explanation of how to use help. This is what the Red console does too.
ALANVF
16:53yeah that's supposed to happen
16:54but I somehow have accidentally fixed the "bug" that lets you leave out function arguments at some point in time
16:54so I need to go back and "unfix" it
hiiamboris
17:10This should only be allowed for arguments accepting unset! type
ALANVF
17:11yeah
17:11or any-type!
hiiamboris
17:11which includes unset ;)
ALANVF
17:12I'd probably have to add a hack/special case for that temporarily, since type signatures aren't actually checked yet

dockimbel
18:02@x8x So, could you figure out how to tie the activity panel in this room to the right repo?

ALANVF
18:04new stuff coming soon-ish
18:04[![image.png](https://files.gitter.im/red/red.js/uKvG/thumb/image.png)](https://files.gitter.im/red/red.js/uKvG/image.png)
greggirwin
18:14:+1:
rebolek
18:29@ALANVF so I tried Red.js again, still no success.
I have Node 13.13.0
I installed typescript with npm install -g typescript , says + typescript@3.9.3
I copied example from README to file test.ts and tried to run it with node test.ts
I got error (node:2711185) Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.
so I added "type": "module" to package.json and
now I get error:
(node:2727770) ExperimentalWarning: The ESM module loader is experimental.                                                                                                                                          
internal/modules/run_main.js:54
    internalBinding('errors').triggerUncaughtException(
                              ^

TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts" for /home/sony/code/Red.js/test.ts
ALANVF
18:29hmm that's odd
rebolek
18:40Ok, thanks. I try and let you know.
ALANVF
18:40:thumbsup:
18:40if you still can't do it, the web repl should work until I fix whatever is causing this issue
rebolek
20:24So my journey continues...after some tries I found out I need to npm i @types/node and then I can tsc --target es2020 test.tswhich finally runs without any errors!
20:24Now I've got test.js which is compiled test.ts I suppose. So, what is next step?
20:39Ok, this one was ugly. I manually added .js to every import in every .js file and now **it works**!
x8x
20:41@dockimbel @hiiamboris Activity panel should now display Red.js/master commits.
ALANVF
20:43nice @rebolek !
20:44(although I thought that you should be able to just do node test.js but whatever)
hiiamboris
20:45@x8x this is what I'm seeing:
![](https://i.gyazo.com/c02c3cea1f04354ac87797c062605bca.png)
20:46could be a gitter glitch though
ALANVF
20:46yea same here
rebolek
20:46@ALANVF I tried but it gives error message on every import, like
Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/home/sony/code/Red.js/red-types' imported from /home/sony/code/Red.js/runtime/datatypes/series.js
ALANVF
20:46I'll have to look into that I guess
20:47glad you got it working though!
rebolek
20:47Yeah, I'm glad too :-) I'll write a guide what needs to be installed in order to get it running.
ALANVF
20:48sounds good :thumbsup:
hiiamboris
20:50okay next commits are visible it seems
ALANVF
20:50nice
20:51Changelog for update 0.0.6:
- Added basic construction syntax support.
- Added value? native.
- Improved some code formatting.
- number! and any-word! are now located in system/words.
- Added and, or, and xor operations for typeset!s.
- pair!, tuple!, and time! no longer box their values (internal).
20:52I'm thinking that I should probably look at using the "releases" feature for future releases btw
20:53that way I can make commits without it having to be an entire update
x8x
20:55There is no way to manipulate or clear current items in the activity panel, flushing the wrong ones with empty items is one workaround.
dockimbel
21:44@x8x Thank you, seems to be working fine now! :+1:
greggirwin
22:09Thanks @x8x. What is the fix, for future reference?
blue13144_twitter
x8x
23:01@greggirwin A custom webhook, unfortunately colors can not be set to make it look like the real one.

greggirwin
00:00OK, thanks.
meijeru
11:11@blue13144_twitter Welcome! May we know a little bit about yourself? There is no profile on Github, I think.

ALANVF
19:01Changelog for update 0.0.7:
- Fixed to action.
- Reimplemented char! and string!.
- Added basic actions for char!.
- Fixed inconsistent mold behavior for string! and char!.
- Fixed pick and poke bugs.
- Added unset native.
- Added more utility functions.
- Fixed a context bug.
- Added union native (paritally).
- Added more supported types for make block!.
- Added to action for block!.
- Added copy action for string!.
- Fixed an issue where function refinements that didn't take any arguments would be ignored.
- Made the interactive help function better.
- Added all typesets.
hiiamboris
19:02:+1:
ALANVF
19:08the repl has also been updated to the latest version for those who want to try it out
endo64
19:22Good progress 👍
ALANVF
19:22thank you!

rcqls
05:23@ALANVF Nice project! I have just tried to execute the code you provide in the REAME and everything works fine with node (not considering the 83 errors in the typescript compilation but I guess it is normal). Following your README you'll plan to offer to run Red.js in the browser (not the repl.it that does not work for me BTW). I guess you have in mind to create a self-contained Red.js file. When do you plan to start it since I think it would be awesome (above all in combination with red/view ).
rebolek
07:46@rcqls what errors do you have in Typescript? I managed to get it down to zero.
rcqls
07:59@rebolek As I said it is just in the compilation (in fact transpilation) process but the generated test.js (and all other js files) was perfect to execute with node. As a part of the output:

red-types.ts:38:6 - error TS1056: Accessors are only available when targeting ECMAScript 5 and higher.

38  get word() {
        ~~~~

red-types.ts:48:6 - error TS1056: Accessors are only available when targeting ECMAScript 5 and higher.

48  get word() {
        ~~~~
…..

514  		return ((1n << (7n - (BigInt(byte) & 7n)) & this.bytes) != 0n) != this.negated;
     		                                                           ~~

red-types.ts:525:16 - error TS2

…..

tokenizer.ts:48:6 - error TS1056: Accessors are only available when targeting ECMAScript 5 and higher.

48  get eof() {
        ~~~

tokenizer.ts:99:27 - error TS2339: Property 'startsWith' does not exist on type 'string'.

99  	const res = this.stream.startsWith(str, this.pos);
    	                        ~~~~~~~~~~


Found 83 errors.
rebolek
08:27@rcqls try tsc -t es2020 test.ts, were -t is target and enables newer features.
rcqls
08:29@rebolek Thanks but still 4 errors:
$ tsc -t es2020 test.ts
red.ts:9:28 - error TS2307: Cannot find module 'fs' or its corresponding type declarations.

9 import {readFileSync} from "fs";
                             ~~~~

runtime/actions.ts:29:20 - error TS2307: Cannot find module 'process' or its corresponding type declarations.

29 import {send} from "process";
                      ~~~~~~~~~

runtime/natives.ts:28:6 - error TS2580: Cannot find name 'process'. Do you need to install type definitions for node? Try `npm i @types/node`.

28  	if(process == null) {
    	   ~~~~~~~

runtime/natives.ts:31:4 - error TS2580: Cannot find name 'process'. Do you need to install type definitions for node? Try `npm i @types/node`.

31  		process.stdout.write(RedActions.$$form(ctx, val).toJsString());
    		~~~~~~~


Found 4 errors.
rebolek
08:30For the process error, do what it says: npm i @types/node
rcqls
08:30@rebolek but it is worth since the test.js no more works!
rebolek
08:30It may probably fix the fs error too, I'm not sure, I need to look.
08:31@rcqls oh...anyway, I was able to get rid of all errors and final test.js worked.
rcqls
08:34@rebolek In my case, the test.js generated bytsc test.js just works fine even after 83 errors of transpilation.
rebolek
08:34Interesting.
08:35I actually first solved the errors and then tried if it's working, so maybe my "broken" version would be able to work too, I just haven't tried before I had error-free compilation.
ALANVF
15:07@rcqls for the record:
tsc: Used for compiling TypeScript to JavaScript.
node: Used for running JavaScript.
15:10other things you may want to do as well:
- make sure you have TypeScript 3.9.2 (or later) installed.
- make sure you have Node 12.13.1 (or later) installed.
- verify that tsconfig.json is in the project directory.
- make sure that you have the NPM package @types/node installed.
15:12if all of those check off but you're still getting errors, let me know and I can try to see what's going on
rcqls
15:59@ALANVF Everything is as you mentionned:
rcqls@macbook-3 ~/tmp/AlanVS/Red.js $ node --version
v14.3.0
rcqls@macbook-3 ~/tmp/AlanVS/Red.js $ tsc --version
Version 3.9.3
rcqls@macbook-3 ~/tmp/AlanVS/Red.js $ npm i @types/node
npm WARN red.js@0.0.7 No repository field.
npm WARN red.js@0.0.7 No license field.

+ @types/node@13.13.9
updated 1 package and audited 1 package in 1.054s
found 0 vulnerabilities

Only 35 errors now after @rebolek told me about npm i @types/node (put above just to check if my install was good).
ALANVF
rcqls
16:00@ALANVF As I told you, the test.js runs properly.
ALANVF
16:00oh ok, so that works?
16:01I'm not sure why you get 35 errors however
rcqls
16:01As a wish, I would prefer to run the test in the browser…. :smile:
ALANVF
16:01have you tried tsc --build?
16:02oh there's a repl that you can use in the browser if you'd like
16:02https://redjs-compiled-repl.theangryepicbanana.repl.run/
rcqls
16:05As I mentionned in my first message, I am not really interested to have a repl, red is perfect. Some sort of transpiling red code to js is much more interesting (or simply as you mentionned it in your README executing red code in the browser). Do you have plan for that?
16:06BTW:
rcqls@macbook-3 ~/tmp/AlanVS/Red.js $ tsc --build ./test.ts
error TS5083: Cannot read file '/Users/rcqls/tmp/AlanVS/Red.js/test.ts/tsconfig.json'.


Found 1 error.
ALANVF
16:06Transpiling to js would be very cool, however due to the structural differences between js and red, it would take a very long time to implement, and it'd probably be more buggier than the interpreter
rcqls
16:10I thought one of your choice about choosing development with typescript would be creation of a standalone file libred.js. In the same spirit [https://opalrb.com/](https://opalrb.com/) is awesome for transpiling ruby to js.
ALANVF
16:11Yeah I'm not saying that it'll never happen, but rather that it'll take quite a while to be able to get there
rcqls
16:13Ok, many thanks for your answer! :ok_hand:
ALANVF
16:13glad I could help :)
rcqls
16:15BTW tsc —build works. The default target is es5 on my computer and the tsconfig mentionned esnext. So everything is fine with this target.
ALANVF
16:15:thumbsup:
rcqls
16:40@ALANVF Also, I quickly created this run.ts script that allows us to execute any red file.
import Red from "./red";

/* this stuff is temporary */
Red.evalRed(`
	get: make native! [[
			"Returns the value a word refers to"
			word	[any-word! refinement! path! object!]
			/any    "If word has no value, return UNSET rather than causing an error"
			/case   "Use case-sensitive comparison (path only)"
			return: [any-type!]
		]
		get
	]
`);
Red.evalFile("./core/natives.red");
Red.evalFile("./core/actions.red");
Red.evalFile("./core/operators.red");
Red.evalFile("./core/scalars.red");
Red.evalFile("./core/functions.red");
Red.evalFile("./core/interactive.red");
/* ------------------------------------- */

var redfile=process.argv[2];
Red.evalFile(redfile);

Maybe you could adapt your app.rb (that looks like a repl) in order to include the execution of red file. Even you could create a bashfile which would be some sort of red-console but with typescript/node engine.
ALANVF
16:41Yeah that's a good idea, I just haven't thought of doing that because it's not practical to use during development :sweat_smile:
16:42and command-line parameters won't work for those who actually run this using browser javascript (as opposed to node, which runs natively)
16:42(although now that I think about it, readline doesn't work in browser.js either)
rcqls
16:43I think it could be good too to execute red test file….
ALANVF
16:43yea probably
meijeru
19:58@ALANVF I notice in your /core/scalars.red the following:
number!:		make typeset! [integer! float! percent! money!]
scalar!:		union number! make typeset! [char! pair! tuple! time! date!]

but in Red, in /environment/scalars.red:
number!:		make typeset! [integer! float! percent!]
scalar!:		union number! make typeset! [money! char! pair! tuple! time! date!]

I suppose you need to correct this.
ALANVF
21:03@meijeru Yeah that's because Red.js has the money! type but the official Red repo does not yet

hiiamboris
08:31even in fast-lexer, it does not belong to numbers, only to scalars
ALANVF
12:57@hiiamboris ah ok. I'll make sure to change that :thumbsup:
14:49yay fixed unset! function arguments
14:49[![image.png](https://files.gitter.im/red/red.js/yDHj/thumb/image.png)](https://files.gitter.im/red/red.js/yDHj/image.png)
hiiamboris
meijeru
19:24@ALANVF Is repl.it updated on the network everytime you update the source, or not? When I go to https://redjs-compiled-repl.theangryepicbanana.repl.run/ I get "not implemented" for many features that you announce as having been implemented. Or do I do something wrong?
ALANVF
19:41@meijeru The version of Red.js on repl.it is updated for every major release (most recent was version 0.0.7)
meijeru
20:14OK so we are still at 0.0.7, which explains why help without argument errors out, right?
ALANVF

ALANVF
18:21Making some progress on parsing date! literals: https://repl.it/@theangryepicbanana/red-date-parsing
greggirwin
18:56:+1:

 12-jan-2020
[eval].ts:1:4 - error TS2304: Cannot find name 'jan'.

1 12-jan-2020
     ~~~

ALANVF
19:07yeah it's not implemented yet
19:07but the parsing rules exist (in the current beta version)
19:09[![image.png](https://files.gitter.im/red/red.js/lIWw/thumb/image.png)](https://files.gitter.im/red/red.js/lIWw/image.png)
greggirwin
19:18Ah, OK.

ALANVF
20:20Changelog for version 0.0.8:
- Added negative?, positive?, max, and min natives.
- Added support for binary! literals.
- Added support for map! literals.
- File loading now works in browser js.
- do now accepts file!s.
- lit-word! arguments that accept unset! now work.
- Added support for tag! literals.
- Added support for date! literals.
20:22as a fun fact, Red.js now supports all literal values (at least to some extent)
greggirwin
20:45Nice! Note that we recently add a ref! form for @reference values.
GaryMiller
22:10@ALANVF Great Progress! Checking for your updated Changelog has become the most exciting part of my day!
ALANVF
22:11Thank you for your support! :)

ALANVF
22:22Got refinements working for natives/actions now :)
22:22[![image.png](https://files.gitter.im/red/red.js/2U85/thumb/image.png)](https://files.gitter.im/red/red.js/2U85/image.png)
22:22(and also fixed refinements for functions in the process)
greggirwin
22:32Cool!

GaryMiller
01:32Bravo!
endo64
10:43Nice!

GiuseppeChillemi
20:11I don't know if this question has already been asked. Why not a transpiler?
GaryMiller
21:26Isn't that what the current compiler does? It has to have some semblance of a interpreter in it to handle all the really dynamic code. Unless it was compiled by a language that was just as dynamic as RED like a common lisp compiler.
ALANVF
21:27perhaps, but there's a good reason why there aren't a whole lot of lisp->js transpilers out there

pekr
04:42I think that for a full fledged Red in a browser (including GUI), it might be more sufficient to have a WASM target and use browser only as a transport layer / container to display the Red app.
ALANVF
18:14new release hopefully coming out sometime today!
rebolek
18:22:clap:
ALANVF
21:59Changelog for update 0.0.9:
- Fixed skip bug.
- Added extract helper function.
- Fixed refinement arguments.
- Improved poke for series! types.
- Unified percent! behavior.
- Added shift native.
- Added trigonometric natives.
- Added nan? and zero? natives.
- Added more math natives.
- Added absolute, negate, and power actions.
- Added (partially incomplete) make/to actions for integer! and float!.
- Added some more helper functions.
23:08yay update 0.1.0 will be able to run the Red demo
23:09[![image.png](https://files.gitter.im/red/red.js/9169/thumb/image.png)](https://files.gitter.im/red/red.js/9169/image.png)

rcqls
00:15:clap: Really good news!
GaryMiller
02:19Will Red.js programs have any size or memory limitations? If for example you had a very large Red program with say 200,000 lines.
03:08@ALANVF I found this.. By default, Node. js (up to 11. x ) uses a maximum heap size of 700MB and 1400MB on 32-bit and 64-bit platforms, respectively.May 16, 2019

But not really sure you could translate those numbers to lines of code very easily or accurately

I was surprised though that jumping from 32 bit to 64 bit only doubled maximum heap size.
toomasv
04:05@ALANVF Great work! :+1:
ALANVF
15:19thank you :)

greggirwin
00:34Indeed. Progress is made by many small steps.
ALANVF
01:26:100:

ALANVF
01:50ye been busy lately
01:500.1 will hopefully come out by/before the end of of june
greggirwin
18:40:+1: Thanks for keeping us posted.

ALANVF
20:47Red.js version 0.1.0 is now out with the following changes:
- Fixed #include directive.
- Fixed get-path/set-path bugs.
- Fixed pick bug.
- print now prints values correctly.
- Added string! comparison.
- Added bit-shift operators.
- Fixed a case bug.
- Added some testing scripts.
- Carets are now allowed in identifiers.
- Fixed to block! for strings and maps.
- Fixed a typo in the tokenizer.
- Fixed some block! and paren! actions.
- Fixed a thing related to map! keys.
- Added some actions for pair!s.
- Fixed bitset! internals.
- Fixed form for refinement! values.
- Fixed mold issues for:
- op!
- native!
- action!
- function!
- context!
- object!
- logic!
- Added form/mold support for most remaining datatypes:
- stringy types
- map!
- unset!
- binary!
- issue!
- time!
- tuple!
- percent!
- hash!
- vector!
- bitset!
- date!
- Accidently broke tests/demo.red (but I'll fix that later).
20:48(the REPL has also been updated to 0.1.0)
greggirwin
20:51Looks like good progress!
ALANVF
20:52Thanks!
21:24I think I've mentioned this before, but please feel free to report any bugs you find with Red.js (since I can't possibly find all of them myself)
GaryMiller
21:28Amazing Progress!

What has been your strategy for deciding what to work on next?

Are you starting with the most low level code and working your way up from there?

Isn't there a higher of top layer code called mezzanine layer that is written in Red code.

At that layer would you just use the existing mezzanine functions in your RED interpreter that has been transpiled to JS or would you need to transpile the mezzanine level functions too for performance or because your lower level data structures for Red internals are different maybe?

meijeru
21:36What progress! But I noticed a small error: extract gets stuck when presented with a block that does not contain a number of components that is a multiple of the second argument.
ALANVF
21:38hmm ok I'll look into that. I think I had the change the source for extract at some point because it used something that I haven't implemented yet (so that's probably why it breaks)
rcqls
22:08@ALANVF playing with demo.red, i > gap-end returns integer 0 (instead of logic false) for i=1 and gap-end=20 interpreted wrongly as true.
ALANVF
22:20ah thanks @rcqls !
22:20yeah I must have overlooked that at some point because the demo was working like a week ago
rcqls
22:25@ALANVF BTW great job! :clap:
ALANVF
22:26thank you :)
rcqls
22:28@ALANVF replacing i > gap-endf with greater? i gap-end makes the demo.red working!
22:29
~/tmp/AlanVS/Red.js $ ./red.sh demo.red

		RedRed              d
		d     d             e
		e     e             R
		R     R   edR    dR d
		d     d  d   R  R  Re
		edRedR   e   d  d   R
		R   e    RedR   e   d
		d    e   d      R   e
		e    R   e   d  d  dR
		R     R   edR    dR d
ALANVF
22:29ah ok (that works for some reason?)
22:29:thumbsup:
22:30that makes me wonder if I accidentally typed an extra 0 at some point somewhere :sweat_smile:
rcqls
22:31
rcqls@macbook-3 ~/tmp/AlanVS/Red.js $ node app.js
> 1 > 10
RawInteger { value: 0 }

> 10 > 1
RawInteger { value: 5 }
ALANVF
22:31waaa
22:32oh I wonder if it's from the bit-shift ops I added
22:32https://github.com/ALANVF/Red.js/blob/master/core/operators.red#L19
22:32lemme see something then
22:33yes it is apparently
22:33[![image.png](https://files.gitter.im/5ec064b3d73408ce4fe3fbdb/H5Wb/thumb/image.png)](https://files.gitter.im/5ec064b3d73408ce4fe3fbdb/H5Wb/image.png)

rcqls
04:04@ALANVF You’re right something goes wrong if you compare :>= and :>:
> :>=
Op {
  name: '>=',
  func: Native {
    name: 'greater_or_equal_q',
    docSpec: RawString { values: [Array], multiline: false, index: 1 },
    args: [ [Object], [Object] ],
    refines: [],
    retSpec: null,
    func: [Function: $$greater_or_equal_q],
    arity: 2
  }
}

> :>
Op {
  name: 'bits',
  func: RawFunction {
    name: '',
    docSpec: RawString { values: [Array], multiline: false, index: 1 },
    args: [ [Object], [Object] ],
    refines: [],
    retSpec: null,
    body: RawBlock { values: [Array], index: 1 },
    locals: [],
    arity: 2
  }
}
04:10And sometimes, :> returns different results:
> :>
Op {
  name: '',
  func: RawFunction {
    name: '',
    docSpec: RawString { values: [Array], multiline: false, index: 1 },
    args: [ [Object], [Object] ],
    refines: [],
    retSpec: null,
    body: RawBlock { values: [Array], index: 1 },
    locals: [],
    arity: 2
  }
}

but also:
> :>
Op {
  name: '>',
  func: RawFunction {
    name: '',
    docSpec: RawString { values: [Array], multiline: false, index: 1 },
    args: [ [Object], [Object] ],
    refines: [],
    retSpec: null,
    body: RawBlock { values: [Array], index: 1 },
    locals: [],
    arity: 2
  }
}
04:16Since :< is ok, demo.red works perfectly when replacing i > gap-end with gap-end < i.
ALANVF
11:59:thumbsup:
13:06I'll hopefully have a fix out sometime today or tomorrow
rcqls
14:13Great! I had no doubt about that BTW! :thumbsup:
ALANVF
19:06ok it's fixed
rcqls
19:23github seems out of order now. I’ll test later your fix!
ALANVF
19:57:thumbsup:
rcqls
20:50@ALANVF Fix confirmed as expected :clap: !
20:53(..subtle fix…great job...)

ALANVF
14:04ye it seems to be a weird regex bug
14:04because <[<=>]|>>> apparently ignores the |>>> or something
14:05add an FAQ btw

ALANVF
21:24btw reimplemented all series! types, so now mutation works correctly :thumbsup:
greggirwin
22:06That sounds like a good bit of work, and very important of course.

GaryMiller
00:47:clap: Great progress!
ALANVF
21:16:100:
ralfwenske
23:45[![image.png](https://files.gitter.im/5ec064b3d73408ce4fe3fbdb/7GPj/thumb/image.png)](https://files.gitter.im/5ec064b3d73408ce4fe3fbdb/7GPj/image.png)

ALANVF
17:49yay finally got insert mostly implemented
17:53(which also means that I can now add repend :tada:)
toomasv
18:08Congratulations! :+1:
ALANVF
18:36thanks!
21:28might get a new release out between now and sunday I think
22:06Red.js version 0.1.2 now out with the following changes:
- Removed pre1 from the preprocessor.
- Reimplemented several series! types.
- Fixed form/mold for binary! values with an offset.
- Added clear action.
- Added remove action.
- Added insert action for any-list!, any-path!, and any-string!.
- Added pad and repend helper functions.
- Redid email!'s implementation.
- Finished implementing append for any-list!, any-path!, and any-string!.
23:54(oh yea, the repl has also been updated)

GaryMiller
01:26Great Progress! :thumbsup:

ALANVF
00:14thank you!
17:18yay vectors now exist
17:18[![image.png](https://files.gitter.im/5ec064b3d73408ce4fe3fbdb/RmLG/thumb/image.png)](https://files.gitter.im/5ec064b3d73408ce4fe3fbdb/RmLG/image.png)
17:24I was able to make them use JS' typed arrays, so they should hopefully be pretty fast compared to normal blocks and stuff
GaryMiller
19:44Very Cool! Can't wait to see some of those benchmarks once you get enough working to run some to the more CPU intense Red demos.

Do you have to worry about the Red Garbage Collector or will the Javascript garbage collector take care of the Red memory fragmentation for you just by marking the variables that go out of scope.
greggirwin
19:46@ALANVF are JS typed arrays the same as, or built on, arraybuffers?
ALANVF
20:56@GaryMiller Yeah I can't wait to run some benchmarks on this stuff. Re: GC, JavaScript's garbage collector should work just fine, however if I ever have it target WebAssembly I'll definitely need to worry about it at some point
20:58@greggirwin They're more similar to ArrayBuffers, as described here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays
21:00the only thing I ran into is that they might be kinda inefficient if you resize them a lot since typed arrays are immutable (for some reason?)
21:01so I have it where whenever you resize a vector, it reassigns the underlying typed array with the new values
greggirwin
21:11:+1:

ALANVF
22:39Red.js version 0.1.3 is now out with the following changes:
- Reimplemented vector!s.
- Added make action for vector!s.
- Add change action.
- Fix insert action.
- Correctly implement copy action.
- Improved form/mold internals.
greggirwin
22:41Nice to see you're still cranking away!
ALANVF
22:42yep, I'm still trying to work on it when I'm not at work whenever I can :)
22:43(although it'd be nice if others could contribute too at some point)
22:44(I would probably have to actually document stuff first though, so it's fine for now I guess)
greggirwin
23:42We know that challenge well.

ALANVF
00:01Yeah, I've wanted to contribute to Red for a long time, but the source isn't really that well documented (especially on the R/S side of things)
00:02Red.js contributes a decent amount though I think ;)
greggirwin
00:05From what I've seen, it's excellent work, and adds a lot of value.
GaryMiller
00:48Red.js opens new hope and potential for the growth of the language!
00:52Thanks for all your hard work!
ALANVF
16:35Thank you all, I'm glad that you all appreciate it!

ALANVF
21:38[![image.png](https://files.gitter.im/5ec064b3d73408ce4fe3fbdb/esGv/thumb/image.png)](https://files.gitter.im/5ec064b3d73408ce4fe3fbdb/esGv/image.png)
21:38yay finally got searching working (only for strings atm)
21:38oh wait that's supposed to return "de"
21:40[![image.png](https://files.gitter.im/5ec064b3d73408ce4fe3fbdb/9Rzj/thumb/image.png)](https://files.gitter.im/5ec064b3d73408ce4fe3fbdb/9Rzj/image.png)
21:40ok that's better
GiuseppeChillemi
22:46Great!

endo64
10:14👏

GaryMiller
14:22How is Red.JS coming along? Hitting any snags?
GiuseppeChillemi
14:38We are all waiting for you Red/web
meijeru
19:16I have noticed that your RawIntegers are not constrained to 32 bits; try 2 ** 33 and it gives you a result without decimal point, unlike Red propoer, which promotes such a number to float.
ALANVF
22:07@GaryMiller it's going decently (although converting R/S to JS is not the easiest thing ever), but I've also been preoccupied with some other things recently too (one of them I might share later since it's Red-related)
22:10@meijeru yeah that's because JS doesn't distinguish integers from floats, so I'm either stuck with the standard "number" type, or the newer "bigint" type once it's added to the EMCAScript standard (because it's currently not supported everywhere)
22:12I _could_ use "typed arrays" like Int32Array, but that'd be fairly inefficient unless I treated it as linear memory (and uh, I'll pass on that for now)

meijeru
12:55In order to be more Red-compliant you could at least check integers for overflow, although that would also be an overhead...
ALANVF
18:25Yeah that extra overhead would be redundant considering the fact that the values are already boxed

greggirwin
01:07If it's performance vs correctness, always choose correctness.
ALANVF
16:37Perhaps, but because this has to run in the browser (rather than locally), it needs to be able to run efficiently enough that it doesn't degrade client-side operations (if that makes sense)
16:38so I can probably add some more checks to make sure that it stays as an integer value, there's a very low chance that I'll be able to emulate the 32-bit overflow/underflow behavior too
16:39(although Math.imul does treat its arguments as 32-bit integers iirc)
GaryMiller
20:20Wouldn't it be just like runtime bounds checking anytime an integer is evaluated you'd just insert lines to raise an exception if it exceeded maxint or was less than minint? You could also have a runtime flag perhaps to turn off integer range checking for those who can't live with the slow down.
ALANVF
20:48@GaryMiller the bounds checking is the slow part because I'd have to do the bounds checking in the RawInteger constructor, which is so inefficient that I may as well just give every RawInteger its own Int32Array. Adding a flag for it would also clutter up the codebase quite a bit, and it's a decent disaster as it is already.

giesse
08:08i am on the side of purposefully breaking bad code.
one day Red may want to use more than 32 bits for integer! as well.
ALANVF
18:27@giesse yeah because the only reason why Red currently doesn't have 64-bit integers is because Red is currently only 32-bit
20:49Hmm so I've been thinking a bit, and what are y'all's thought's on switching Red.js over to something like Haxe instead of TypeScript? Although it would be a bit slower and probably come with some extra bloat (in the runtime), it would be far easier to work with than TS because of it has so many more features than TS will ever have (for the foreseeable future)
20:50Dart could be another viable option too, although it sits somewhere inbetween TS and Haxe in terms of language features
20:51but honestly like obviously TS compiles directly to JS and is much faster/optimized that way, but it's a lot less fun and productive than alternatives
20:53(the reason I mention this is because Dart and Haxe can also compile to JS, and therefore run in the browser)
21:00For example, the following TS code:
let str2: string;

if(value instanceof Red.RawWord) {
	str2 = value.name;
} else if(value instanceof Red.RawString) {
	str2 = value.toJsString();
} else if(value instanceof Red.RawBinary) {
	str2 = value.bytes.ref.toString();
} else {
	str2 = RedActions.$$form(ctx, value).toJsString();
}

could easily be written in Haxe as:
final str2 = switch(value) {
	case Red.RawWord: value.name;
	case Red.RawString: value.toJsString();
	case Red.RawBinary: value.bytes.ref.toString();
	case _: RedActions.form(ctx, value).toJsString();
};
21:01not only is the Haxe code cleaner and more concise, but it also allows me to declare str2 as a constant rather than a regular variable (like in the TS code), which can obviously make the code a bit faster
theSherwood
21:02Seems like it depends a lot on what your long term goals are for the project.
ALANVF
21:04Yeah I haven't really thought too much about Red.js' long-term goals yet, but I mainly just want it to act as web runtime for Red
21:04although maintainability is definitely important to keep in mind, which is what got me thinking about this
theSherwood
21:06Right. My take is that if you are going to be doing the maintenance long term, do it in the language that is going to work best for you. If you want more community involvement at some point in the future, Typescript may be best.
21:09Simply on account of it being fewer languages for contributors to need to know in order to contribute.
ALANVF
21:13Yeah that's what I'm thinking
21:15I've considered using something like Babel to be able to use stuff like "do-expressions proposal" (basically turns a statement into an expression), but many editors don't support Babel extensions, and I also want to keep the number of dependencies that Red.js requires to a minimum (similarly to normal Red)
theSherwood
21:19I was not aware of that proposal. Very cool.
21:21Are you wanting to minimize all dependencies or just runtime dependencies? Because Typescript is already a sizable build dependency. I don't see what harm a few Babel plugins could do in that regard.
ALANVF
21:21Yeah I'm really hoping that the TC39 proposal gets past stage 2 because I absolutely love the idea
21:21I would like to minimize runtime dependencies at a minimum
21:22Babel could be fine as a dev dependency (and will probably be added at some point), but then there's the editor issue that I mentioned earlier regarding the do-expressions thingy
theSherwood
21:24Yeah. That's an issue. Though if someone is going to be writing much Typescript, they might be better off using an editor built for the ecosystem anyway...
ALANVF
21:26Well sure, but the issue is that there aren't any editors that support plugin/proposal (yet)
21:26I'd imagine that basic support would be added when it hits stage 2, but that could take even another year to happen
theSherwood
21:30Gotcha. That makes sense.
ALANVF
21:40I suppose that the best thing to do for now is to use the most up-to-date versions of TS to enable newer features and whatnot
GaryMiller
21:44Interesting... The advantage I see with Haxe is you can compile it to C. From there you can use Emscipten to compile the C code to WASM which should be a lot faster than JavaScript but you lose the DOM.

The other advantage is you could compile the C to a 64 bit .exe and lose any of the 32 bit size limitations which would really float my boat.

The only con I see is that Haxe has been around for a while and it hasn't climbed very far up the Tiobe Index as far as I can see.
ALANVF
21:46Yeah and I also think that Haxe is bigger for gamedev rather than appdev as a whole
21:47although tbh, It couldn't hurt to at least make a small prototype in Haxe sometime I guess
22:17Red.js version 0.1.4 is now out with the following changes:
- Implemented reflect action for object! and map!.
- Finished implementing foreach.
- Added more helper functions.
- Fixed quoting issues with set-word! and set-path!.
- Fixed quoting bugs for get-word! and lit-word! function arguments.
- Fixed lit-word! and lit-path! behavior.
- Removed multiline property from string!s because it wasn't needed.
- Fixed file error bug.
- Added to- helper functions.
- Added find action for any-string! and typeset!.
theSherwood
22:53:thumbsup:

GaryMiller
01:03:100:
01:15The run-time performance of Haxe programs varies depending on the target platform:

ActionScript 3: Programs produced using the Haxe compiler usually run faster than programs produced using the Apache Flex SDK ActionScript Compiler. However, using ActionScript Compiler 2 (ASC2) with manual optimizing, many have reported comparable performance.

JavaScript: Programs produced using the Haxe compiler run at a comparable speed to handwritten JavaScript programs. OpenFL is a common Haxe-powered framework that can run in HTML5-JavaScript, but content built with OpenFL currently suffers performance issues on mobile devices.

C++: Programs produced using the Haxe compiler rival handwritten C++ programs, but C++ applications built with OpenFL suffer major performance issues.

https://en.wikipedia.org/wiki/Haxe#Performance_comparison
GiuseppeChillemi
07:43Haxe "a language built to transpile in other languages" interesting.
ALANVF
14:23Yeah it's definitely an interesting concept, because it can essentially run anywhere with little modification
GiuseppeChillemi
20:38There is a lot of knowledge in Haxe transpiling technology, it's worth to keep a foot it that shoe. The run everywhere feature is very appealing and despite some possible performance problem a version of Red written in that language can really run everywhere!

ALANVF
01:40conversation in red/red just reminded me that I need to figure out how to implement bind somehow
01:40it seems to be more magical than I'd prefer
giesse
07:39that suggest that your implementation of word! is wrong :)
ALANVF
13:38@giesse yes that's highly likely, as I didn't know what bind did (and still don't completely know) when I was first making Red.js
GiuseppeChillemi
14:03It's incredible how you are porting Red without binding. It is the most basic concept behind relative words.
14:19I can summarize it as follow: in Red the value of a word is taken from multiple tables, you have system/words table and all the others which are created at runtime when you make an object. Each word has a connection that can be to any of these tables ) but only if it already exists in that table). The interpreter uses this connection to take the value of the word. Bind role is just to change the connection of a word, or the words of an entire block, to another table (object) you express in the form bind WORDs TABLE(object). If the word exists in the target table it will be reconnected. After the binding, all the words value of the block will be taken by the interpreter from this table.
giesse
18:42in case it's helpful as a reference: https://gist.github.com/giesse/3ebac89c91ec8cbb06420f62d6b9dff2#file-topaz-js-L1013
18:44https://gist.github.com/giesse/3ebac89c91ec8cbb06420f62d6b9dff2#file-topaz-js-L1393 etc.
18:45note that offset is an optimization and is not really necessary in principle.
ALANVF
23:51ahhhhh ok that seems a lot easier than what I've been doing so far
23:52that would also explain my frustration with various parts of the implementation such as objects and functions
23:54honestly at this point, I actually think that it'd be worth switching to another language or something to make it easier to redo everything
23:55or, if it's ok with y'all, I can try to redo it in typescript but it'd take much more time to do so
23:57although lately, I've been brainstorming some ideas for alternatives that I could use for Red.js instead of typescript, due to many of its minor annoyances
23:59Haxe (which has been discussed here already) seems like an ideal solution

ALANVF
00:00ReScript (new version of ReasonML) also seems viable, but it still shares a lot of the issues that ReasonML failed to fix
00:01Fable (F#-to-js compiler) also seems nice, but also seems to come with a decent amount of overhead
00:02Scala.js also seems nice (and just recently hit 1.0!), but it also has a lot of runtime overhead
GaryMiller
00:04What would be the target language for Haxe still js?

Would it still be web enabled?

Would Haxe still be a simple distribution model? (Just an .exe and a few DLLs)
ALANVF
00:06Well, the thing about Haxe is that you can run it essentially anywhere
00:07so it can be compiled to js, php, c++, java, c#, and so on
00:08and while there are minor inconsistencies between targets, they all essentially work the same way
00:10I think that for now, I might try writing a small subset of Red.js in Haxe and see what happens
giesse
09:07Personally, if I was doing this, I would write my own compiler.
But, as a general advice, you want a language that is as high level as possible and that compiles down to as many different platforms as possible. If Haxe works for you, go for it, in the worst case you'll learn why it's not a good idea :)
ALANVF
23:35:100:

ALANVF
20:06[![image.png](https://files.gitter.im/5ec064b3d73408ce4fe3fbdb/iLjG/thumb/image.png)](https://files.gitter.im/5ec064b3d73408ce4fe3fbdb/iLjG/image.png)
20:07New parser written in Haxe :)
20:27although there have been some minor inconveniences (such as [this](https://pastebin.com/fwqeAy7K) taking > 30min to compile due to a codegen bug), I definitely think that Haxe was the right way to go
20:48[![image.png](https://files.gitter.im/5ec064b3d73408ce4fe3fbdb/b9Pr/thumb/image.png)](https://files.gitter.im/5ec064b3d73408ce4fe3fbdb/b9Pr/image.png)
20:48oh yeah it also seems to be pretty fast

GaryMiller
03:04Surprising that you would find a codegen bug this early on in your conversion since the language is so mature. Were you able to work around the bug or is the 30 min compile time something you'll have to live with going forward?

Do they have a symbolic debugger for Haxe for when you run into logic issues or will you still have to rely on good old probe?
ALANVF
14:08@GaryMiller I was able to work around the bug by rewriting that section of code differently, so it's no longer an issue :thumbsup:
GaryMiller
20:00@ALANVF Found this .... Haxe is supported in a number of editors and IDEs. Some IDEs, such as Visual Studio Code (with the vshaxe extension), support debugging of Haxe code with breakpoints, stack tracing, etc. More information is available on the vshaxe wiki. https://haxe.org/manual/debugging-ide-integration.html

ALANVF
18:21@GaryMiller yeah but I'm too lazy to learn how the debugger works. plus, I found an issue on their github about the problem I was having, and it seemed valid to me (it was generating massive if/else chains), so it's fine now

ALANVF
22:02Status update for Red.js: https://github.com/ALANVF/Red.js#status-update
22:06making the switch from TS to Haxe :)

GaryMiller
15:47@ALANVF How's the JS to HAXE code conversion going. Is the new context implementation going smoother now?
ALANVF
18:14@GaryMiller Yeah it's going pretty nicely. Definitely easier than the TS implementation
18:15I'll probably make a temp repo for it once I get most of the core datatypes added
18:17Haxe has required a lot more boilerplate code than TS (it doesn't even have builtin sets?!), but it's otherwise been nice
GaryMiller
18:41@ALANVF Glad that it's easier than TS. I read that HAXE has pretty good macro capability but that its an advanced feature and harder to learn. They may be good for some of those boilerplate situations though.

ALANVF
17:42the Haxe version Red.js is now on github! https://github.com/ALANVF/Red.js-haxe
theSherwood
17:47Well done!
ALANVF
17:47Thank you!
17:48it's definitely taken quite a bit to get to this point
17:48but it was definitely worth it imo
theSherwood
17:48Seems like a whole lot of work. I'm excited to take it for a spin when it's ready!
ALANVF
17:48yep I can't wait for it to be functional
17:50and for those of you who couldn't try it because node.js was being a pain (or something related), Haxe can compile to more languages than just js :)
17:52so you could theoretically just have it compile to lua or python and use it instantly
theSherwood
18:11:thumbsup:
GiuseppeChillemi
23:28Wow!

ALANVF
02:49oh yeah if anyone wants to help with the transition process, please feel free to do so!
02:50Haxe is a lot easier than TypeScript, so that might be more appealing to those who weren't a huge fan of TypeScript

greggirwin
01:57Thanks for the update @ALANVF!
GiuseppeChillemi
22:01This room should be RED.haxe ;-)
22:02Also, it would be great a RED would compile to HAXE, then the HAXE transpiler could output it to any HAXE supported language.
ALANVF
22:22Yeah maybe, although the original intention of the project was to be able to run Red in the browser

greggirwin
17:56@GiuseppeChillemi :^)
GiuseppeChillemi
20:33@greggirwin "subliminal hypnotic suggestion"
greggirwin
22:02It's not *very* subliminal.
GiuseppeChillemi
22:07Yes, direct and not concealed!

ALANVF
16:27More progress made today: https://github.com/ALANVF/Red.js-haxe/commit/721bcf0319e7f6b9024ffc57e61cdfe7fb720541
20:21also hoping to get some docs in the code (somewhat) soon for anyone who wants to contribute

GiuseppeChillemi
06:28@ALANVF great work, you are giving us a dream: having Red in the browser.
ALANVF
14:46tysm :)
14:47I've wanted Red in the browser ever since I discovered it, and now we're getting closer to making that reality

ALANVF
01:23had some ideas about a JS dialect for Red.js:
Red/JS []

#import [
	console: "console" object! [
		log: "log" function! [
			[variadic]
			args    [block!]
			return: [unset!]
		]
	]
]

console/log [1 2.3 "abc"] ;=> 1 2.3 'abc'

;-- Resulting JS code:
; console.log(1, 2.3, "abc");
01:26tried to make it look a bit similar to R/S
01:35(more is available in the latest commit)
01:38apologies for the inactivity btw. been occupied with school and stuff
greggirwin
05:11Cool idea. Thanks for the update. We all get busy at times.

ALANVF
20:27Yay more progress today
20:27started working on evaluation
20:28https://github.com/ALANVF/Red.js-haxe/blob/master/src/runtime/natives/Do.hx
20:28and this time, no obscure hacks were required when parsing operators ;)
greggirwin
20:30:+1:
GaryMiller
22:57Great progress! Glad you're sticking with it.
GiuseppeChillemi
22:58Nice!
ALANVF
22:59thanks for the support!

ALANVF
01:35(Basic) evaluation is now done! https://github.com/ALANVF/Red.js-haxe/blob/master/src/runtime/natives/Do.hx
01:36planning to move this code to the main Red.js repo once I get some basic actions/natives added
greggirwin
02:20:clap:
rcqls
08:20:clap: :clap:
meijeru
15:02Did anyone notice that the "FizzBuzz" example in the Red.js Readme is flawed?
repeat i 100 [
	switch 0 [
		i % 15 [print "FizzBuzz"]
		i % 3  [print "Fizz"]
		i % 5  [print "Buzz"]
		0      [print i]
	]
]

The body-block of the switch should have reduce in front of it, since switch guards are literals .
15:04With that amendment, it is an interesting idiom, that I had not encountered before. Who would think of putting the constant as the switch value and the variable expressions in the guards? Naively, one would write a casewith guards zero? i % 15 etc.
15:05Interesting to speculate about relative timing of switch vs case.
ALANVF
15:18@meijeru I could have sworn that switch reduced its contents
15:19I happened to get the idiom from js though, since it's pretty common there
15:20I wonder if there could be a refinement or something for switch that'd reduce its contents as it goes through each case
15:21kinda like all/any short-circuit evaluation
greggirwin
17:51It's interesting but, having never used it, doesn't make sense to me. Most interesting is why switch even supports literal values rather than variables. That is, switch by its very name implies dispatching based on a value that may change. It's like saying if true .... Switch already doesn't let you use blocks as values to dispatch on. @meijeru please think on that as a design point and pose it to the community with your thoughts.
17:53I have an old select-case mezz, which is a dialected version of the old BASIC construct, which makes common dispatching cases on ranges convenient and declarative.
GiuseppeChillemi
18:05@greggirwin Have you it as gist?
greggirwin
18:11I don't know if I've even ported it to Red. Will have to look, but have other pressing tasks ATM.
GiuseppeChillemi
18:11Not so urgent, just curious
greggirwin
18:15You may have gotten lucky....
18:21I just now pulled old tests, some of which are failing, so clearly haven't used this in Red. It will give you the idea though.

[select-case gist](https://gist.github.com/greggirwin/5020d92e4e8f3785b307785cacdab5ce)
GiuseppeChillemi
18:23Thank you. I have in mind a Select which works on different types of selections/grouping. So your will be a source of further ispiration.
greggirwin
18:35Note that between? is one of those tricky things, which has to be considered for pragmatic clarity versus, perhaps, a more rigorously correct interpretation. e.g. do you want to spec ranges as 1..10 10..20 or 1..10 11..20.
18:37I don't remember why I changed it in the Red version, but I see my old R2 version used <= for the upper bound.

ALANVF
17:08more things are working!
17:08[![image.png](https://files.gitter.im/5ec064b3d73408ce4fe3fbdb/zPM0/thumb/image.png)](https://files.gitter.im/5ec064b3d73408ce4fe3fbdb/zPM0/image.png)
rebolek
17:39:+1:
greggirwin
18:12Are "things" literal logic! syntax, or either? Either way, cool.
ALANVF
18:12literal logic! syntax has existed for a while, but functions are new
18:12either way, yeah pretty cool
18:13right now, I'm trying to figure out how to structure the dispatch functionality for actions
18:14RTTI would be easy, but it's a cheap shortcut and won't work on static Haxe targets (like c++ and java)
18:18(for reference, RTTI does not preserve static type information, which results in a loss of type safety and static type information)
greggirwin
18:19You can't add actions at runtime, so just a table of function pointers, as in Red itself, should work. I don't know how the rest of it is structured in red.js, so it may not be as simple as I imagine.
ALANVF
18:20it's similar to that, but in Red.js I was not preserving type information because I was lazy (and TS probably didn't care much anyways lol)
18:21hmm I might have an idea actually
18:22do you know if there are any actions that are intentionally not inherited (from the inherited actions table) for any datatypes?
greggirwin
18:24It seems like if you don't have type information, it will be hard to do even things like type?, won't it?

Every type chooses what to override or not. The more that a base type can handle, the less code we have to write, but that can also lead to unexpected behavior, where an action later has to be overridden to make a type work more as users expect.
ALANVF
18:25well with type? it's pretty easy because the actual type system uses class inheritance to emulate Red's hierarchy
18:26so each class has a function (generated by a macro, thankfully) that returns its datatype info
18:27the issue with actions is that they are separate from the actual type system
greggirwin
18:30Bearing in mind that I'm ignorant of the internals, what I say may not make sense. But if you're generating funcs like that, can't you also generate the actions? I have no idea how ugly that will be when it comes to inheritance, but you could bake the inherited funcs into each class, rather than relying on class inheritance in the target lang. Basically, actions are only used as values to map to those funcs.
ALANVF
18:31so basically, I have 2 options: put the code for each datatype's actions in the corresponding class implementation (easy, but will make files absolutely massive), or implement them separately and use some sort of tagging mechanism to lookup a value's dispatch table (harder (and possibly slower), but will make files shorter and more organized)
18:31yeah basically
18:32however, putting the code for the actions in their corresponding classes will probably clutter up the codebase
18:33because then you have dozens 2k+ loc files for the datatypes
18:33hopefully that's making sense
18:34I do have some actions implemented like this already, but they are fairly basic and do not interface with Red itself, which is fine I guess
18:35here's an example: https://github.com/ALANVF/Red.js-haxe/blob/master/src/types/base/_SeriesOf.hx
18:37so yeah it implements some common series! methods, but they're really only made for Haxe code so they're a lot shorter than implementations of the actual Red functions
greggirwin
18:38This is where you want a dialect that lets you write things in a clear way, then generates all the ugly guts. ;^) And 2KLOC isn't terrible. Go for what's obvious and easy to understand and maintain, unless it's absolutely unworkable.
ALANVF
18:38Yeah I could probably make some macros for the actions and stuff I guess
18:39I have a "build macro" in the Value class for generating things like the type info methods that I mentioned earlier: https://github.com/ALANVF/Red.js-haxe/blob/master/src/types/Value.hx#L13
18:40otherwise, that sounds like a plan :thumbsup:
GaryMiller
20:42If I am understanding correctly wouldn't generics help here?

You could have a base class where the common methods (actions) were inherited where possible.

And still override them when the inherited method was not correct for that datatype's action.
ALANVF
20:44I don't think generics are exactly related (I also tried using them for actions in TS, and did not like the result), but yes the latter part is what I've doen
GaryMiller
20:48Great progress! :thumbsup:

ALANVF
22:27lots of progress today :tada:
22:27[![image.png](https://files.gitter.im/5ec064b3d73408ce4fe3fbdb/iwWr/thumb/image.png)](https://files.gitter.im/5ec064b3d73408ce4fe3fbdb/iwWr/image.png)
GiuseppeChillemi
22:47@ALANVF :clap: :clap: :clap: :clap:

greggirwin
00:58Nice. :+1:
GaryMiller
05:34Keep up the great work! :clap: :clap: :clap: :clap:

ALANVF
16:34code from Red.js-haxe has now been moved to the main repo!
GaryMiller
17:02Great!
greggirwin
22:00Thanks for keeping up posted.
ALANVF
23:10:thumbsup:

ALANVF
19:57yay more things
19:57[![image.png](https://files.gitter.im/5ec064b3d73408ce4fe3fbdb/6sJC/thumb/image.png)](https://files.gitter.im/5ec064b3d73408ce4fe3fbdb/6sJC/image.png)
22:46hey does anyone know how/where self is stored in objects?
greggirwin
22:47Nice! With so many details and features, you really have your work cut out for you.
22:51Check out save-self-object in %object.reds.
ALANVF
22:51cool thanks
22:52I'm trying to figure out whether or not it's supposed to be stored in the object's symbol table to prevent bugs that I may or may not have just run into
greggirwin
22:53It's a special hidden cell.
ALANVF
22:53hmm ok then
22:53that shouldn't be too hard to implement I don't think
22:54because I was implementing get and set and was accidentally changing the self value of objects because it's the first entry in their lookup tables
greggirwin
22:56
>> o: object [who-am-I?: does [self]]
== make object! [
    who-am-I?: func [][self]
]
>> o/self
*** Script Error: cannot access self in path o/self
*** Where: catch
*** Stack:  

>> o/who-am-I?
== make object! [
    who-am-I?: func [][self]
]
>> in o 'self
== none
ALANVF
22:59ah gotcha

giesse
10:08that's different from R2 though...
>> o: make object! [a: 1]
>> o/self
>> in o 'self
== self
greggirwin
17:04Indeed. The change was made in R3.

Numeross__twitter
11:28Is there some not too hard work I could help with ?
ALANVF
14:36@Numeross__twitter Yeah if you're familiar enough with Haxe, maybe you could try implementing the form/mold actions? Or if that's too hard (since there aren't many docs lol), maybe trybadding date! or raw-string! rules to the tokenizer?
14:37(raw-string! would probably be the easiest though)
14:37thanks btw!