Currently (v0.6.3), the implementation of the DAP specification in da_server/1 is interwoven with logic that is specific to the use case of debugging (SWI-)Prolog programs.
It seems desirable to separate these concerns into two components, say dap_server and dap_swipl, such that dap_server will implement only the generic framework for easily adapting debuggers in a manner conforming to the DAP specs, while dap_swipl will encapsulate the specifics of adapting the SWI-Prolog debugger with all of its nitty-gritty details.
This will allow for (re-)using the dap_server component for creating DAP servers for any language that is implemented on top of SWI-Prolog with minimal effort, by implementing only the logic that is specific for the target language's semantics.
Such languages include s(CASP), CHR, Logtalk and probably more.
Currently (v0.6.3), the implementation of the DAP specification in
da_server/1is interwoven with logic that is specific to the use case of debugging (SWI-)Prolog programs.It seems desirable to separate these concerns into two components, say
dap_serveranddap_swipl, such thatdap_serverwill implement only the generic framework for easily adapting debuggers in a manner conforming to the DAP specs, whiledap_swiplwill encapsulate the specifics of adapting the SWI-Prolog debugger with all of its nitty-gritty details.This will allow for (re-)using the
dap_servercomponent for creating DAP servers for any language that is implemented on top of SWI-Prolog with minimal effort, by implementing only the logic that is specific for the target language's semantics.Such languages include s(CASP), CHR, Logtalk and probably more.