Skip to content

Should argv clone the array? #8

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
no-longer-on-githu-b opened this issue Nov 27, 2016 · 7 comments · Fixed by #26
Closed

Should argv clone the array? #8

no-longer-on-githu-b opened this issue Nov 27, 2016 · 7 comments · Fixed by #26
Labels
purs-0.14 A reminder to address this issue or merge this PR before we release PureScript v0.14.0

Comments

@no-longer-on-githu-b
Copy link

Get an array containing the command line arguments. Be aware that this can change over the course of the program.

Does this mean the array itself may change? Because if that happens, then argv should return a clone of the array to keep users of the array referentially transparent.

@hdgarrood
Copy link
Member

Yes, the array itself can change, if you do something like process.argv.push('wat') in JS. I agree, cloning the array seems like the right thing to do. We might also consider exposing an API from this library that lets you mutate process.argv too.

@thomashoneyman thomashoneyman added the purs-0.14 A reminder to address this issue or merge this PR before we release PureScript v0.14.0 label Dec 9, 2020
@thomashoneyman
Copy link
Contributor

I think we should try and fix this for the upcoming 0.14 release for this library.

@jvliwanag
Copy link
Contributor

jvliwanag commented Dec 11, 2020

Perhaps we can simply set the type of argv as STArray Global String? This adds a dependency on st though.

@jvliwanag
Copy link
Contributor

Also, should we do the same for execArgv and env?

@hdgarrood
Copy link
Member

I think I’d prefer just providing a pair of Effect functions to get and set these values, eg argv :: Effect (Array String) and setArgv :: Array String -> Effect Unit

@jvliwanag
Copy link
Contributor

The neat think on the ST Global stuff is we can skip having to write custom ffi for freezing arrays and objects (for env). We can even delete the current ffi for setEnv and unsetEnv.

We can always just hide the functions exposing ST Global if that's an issue. Or are we better off keeping it simple and dropping the ST Global entirely?

@hdgarrood
Copy link
Member

While it makes perfect sense to avoid FFI where possible in most contexts, I don’t think libraries whose purpose is to provide bindings to JS APIs is one of them. I think having custom FFI for these is fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
purs-0.14 A reminder to address this issue or merge this PR before we release PureScript v0.14.0
Projects
None yet
4 participants