From fde6da031c8e9b09f882f58698341e52ee7fc13d Mon Sep 17 00:00:00 2001 From: Steffen Forkmann Date: Tue, 14 Mar 2017 21:07:22 +0100 Subject: [PATCH] update load workflow --- RFCs/FS-1027-fsi-references.md | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-) diff --git a/RFCs/FS-1027-fsi-references.md b/RFCs/FS-1027-fsi-references.md index 382cc834..1a510dfa 100644 --- a/RFCs/FS-1027-fsi-references.md +++ b/RFCs/FS-1027-fsi-references.md @@ -114,25 +114,23 @@ Behavior should not be so different at runtime. When executing code interactive When launching FSI with a script using one of the new `#r` references, FSI will do the following: -1. Check if each dependency exists in the known place for the specified tool. If it does, `#r` that dependency when executing FSI. -2. If a dependency does not exist, search for the tool in a known/blessed area. Error out if it can't be found. -3. Call out to the tool to resolve dependencies. -4. `#r` the resolved dependencies in an ephemeral script (or the script generated by Paket if using Paket). -5. `#load` that script into the FSI session, thus giving it the references it needs to execute. +1. Check which tools is registered for a given #r prefix. Error out if no tool can't be found. +2. Let the tool check if each dependency exists in the known place for the specified tool or otherwise the the tool resolve all dependencies. +3. `#r` the resolved dependencies in an ephemeral script (or the script generated by Paket if using Paket). +4. `#load` that script into the FSI session, thus giving it the references it needs to execute. ### Running a script in an active FSI session This scenario is as follows: I have launched FSI at some point, and now I wish to execute a script which may or may not have references that I already have loaded into FSI. The behavior should actually be the same as if FSI were launched with the script: -1. Check if each dependency to be loaded exists in the known place for the specified tool. If it does, `#r` that dependency when executing FSI. -2. If a dependency does not exist, search for the tool in a known/blessed area. Error out if it can't be found. -3. Call out to the tool to resolve dependencies. -4. `#r` the resolved dependencies in an ephemeral script (or the script generated by Paket if using Paket). Check version numbers against what we already have loaded in the FSI session. If any `.dll` names and versions match, don't `#r` them into the script. -5. `#load` that script into the FSI session, thus giving it the references it needs to execute. +1. Check which tools is registered for a given #r prefix. Error out if no tool can't be found. +2. Call out to the tool to resolve dependencies. +3. `#r` the resolved dependencies in an ephemeral script (or the script generated by Paket if using Paket). Check version numbers against what we already have loaded in the FSI session. If any `.dll` names and versions match, don't `#r` them into the script. +4. `#load` that script into the FSI session, thus giving it the references it needs to execute. This is because: -1. A reference may already be loaded for the current FSI session, but a differen version was specified in that script. We need to allow that to error out, because the script code may depend on a higher or lower version than what is already loaded. That could cause a runtime error if we just allowed it to run on whatever we had already loaded. +1. A reference may already be loaded for the current FSI session, but a different version was specified in that script. We need to allow that to error out, because the script code may depend on a higher or lower version than what is already loaded. That could cause a runtime error if we just allowed it to run on whatever we had already loaded. 2. It's too complicated to attempt to only partially load stuff if something is already referenced. ### Referencing a new dependency in an active FSI session