freenode/#abcl - IRC Chatlog
Search
15:33:03
jcowan
easye: I wanted to understand how it was done, not to make use of it, because I am looking into ways of reflecting foreign errors into Lisp. In the case of a C-type error, just synthesizing a condition object makes the most sense, but in Java or C# or Python it makes more sense to preserve the foreign condition object by wrapping it in a native object, I think. But thanks for asking.
16:03:55
alandipert
jcowan that makes sense to me too, i'd be interested in whatever related work you share. at some point i'll have to implement in mine, for JS exceptions
16:05:14
jcowan
I also need to look at Kawa Scheme and IronScheme, which are Schemes for the JVM and CLR.
16:07:07
alandipert
for my part i'm trying to find a good balance of CL affordances and efficiency/runtime minimalism, JS platfrom comparatively constrained. and i want to eventually be able to use JACL for work, where it would need to compete with JS
16:08:34
alandipert
it's very rough. but i've worked on it consistently over a long period of time in a way i haven't on any other project, so here's hopin'
16:12:03
jcowan
Something that popped out at me: I'd make sure that Lisp strings and JS strings have the same representation, even though JS strings are immutable. The Scheme community has done some work on having both mutable and immutable strings fit into a framework that originally assumed only mutable strings.
16:20:14
alandipert
interesting, i'll have to dig into that. it would be great if it were achievable
16:21:25
alandipert
is the general idea there that the immutable rep. is default, and any mutable operation "upgrades" the string wherever referenced?
17:01:40
jcowan
The idea is to change the semantics of certain CL functions to produce immutable strings, but in such a way that attempts to mutate them will fail fast.
17:04:23
jcowan
Principles: literal strings are immutable (already true), nonsimple strings are mutable, string transformers return immutables, string copiers return mutables.
18:12:48
alandipert
hm, i'm not sure about changing standard behavior by signaling errors. but you helped me realize the CL function behavior over immutable strings could be implementation dependent
18:13:23
alandipert
e.g. use my implementation-dependent way of constructing an immutable string, and it will behave naturally as it flows through the standard CL string functions
18:14:05
alandipert
...maybe that's the same thing you said though? i'll definitely have to think more about this, thanks for the suggestion
21:29:16
jcowan
Since you are not trying to be 100% ANS-compatible, how about this plan: literals are I, STRING returns M, STRING-UPCASE etc. returns I, STRING-TRIM etc. returns I, MAKE-STRING returns M, MAKE-ARRAY returns M, COPY-SEQ returns M, MAKE-SEQUENCE returns M, SUBSEQ returns I, REVERSE returns same type as argument, CONCATENATE returns I if all args are I but otherwise M, DELETE returns same type as argument, DELETE-DUPLICATES