--
You received this message because you are subscribed to the Google Groups "Shen" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qilang+unsubscribe@googlegroups.com.
To post to this group, send email to qil...@googlegroups.com.
Visit this group at https://groups.google.com/group/qilang.
For more options, visit https://groups.google.com/d/optout.
To unsubscribe from this group and stop receiving emails from it, send an email to qilang+un...@googlegroups.com.
I've long felt a feature that's been lacking in Shen is the ability to do pattern matching in places other than function parameters. It's annoying to have that functionality at the start of a define and then have to revert to writing hd/tl calls later on in the same function.Here's a prototype for a match expression, re-using the parser code for functions. It uses F# keywords but takes multiple argument expressions like a Shen function. Contrived usage:(match List N with_ 0 -> 0[X | Xs] N -> (+ (* X N) (recur Xs N))[] N -> (error "empty list"))(no patterns matched fails like a partial function - prompts for tracking)I noticed there's a macro to do pattern matching in lambdas in the shen-libs repo, and this would be in the same spirit. (does this still work with newer versions of the kernel? "shen-<define>").
Should these things just be in a library or part of the kernel? It feels arbitrary to have only global function parameter pattern matching built-in, but not these other 2 forms.
--
You received this message because you are subscribed to the Google Groups "Shen" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qilang+unsubscribe@googlegroups.com.
To post to this group, send email to qil...@googlegroups.com.
Visit this group at https://groups.google.com/group/qilang.
For more options, visit https://groups.google.com/d/optout.
On Mon, Jan 8, 2018 at 5:44 PM, Robert Koeninger <rkoen...@korewireless.com> wrote:I've long felt a feature that's been lacking in Shen is the ability to do pattern matching in places other than function parameters. It's annoying to have that functionality at the start of a define and then have to revert to writing hd/tl calls later on in the same function.Here's a prototype for a match expression, re-using the parser code for functions. It uses F# keywords but takes multiple argument expressions like a Shen function. Contrived usage:(match List N with_ 0 -> 0[X | Xs] N -> (+ (* X N) (recur Xs N))[] N -> (error "empty list"))(no patterns matched fails like a partial function - prompts for tracking)I noticed there's a macro to do pattern matching in lambdas in the shen-libs repo, and this would be in the same spirit. (does this still work with newer versions of the kernel? "shen-<define>").No, it has two issues, shen-<define> is now called shen.<define>, and it passes a symbol instead of a function (that works in SBCL and maybe other ports too, but it is not portable).But it is easy to fix: https://github.com/vasil-sd/shen-libs/pull/21/files
--Should these things just be in a library or part of the kernel? It feels arbitrary to have only global function parameter pattern matching built-in, but not these other 2 forms.
You received this message because you are subscribed to the Google Groups "Shen" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qilang+unsubscribe@googlegroups.com.
To post to this group, send email to qil...@googlegroups.com.
Visit this group at https://groups.google.com/group/qilang.
For more options, visit https://groups.google.com/d/optout.
--BD
To unsubscribe from this group and stop receiving emails from it, send an email to qilang+unsubscribe@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to qilang+unsubscribe@googlegroups.com.
Tatsuya,Yeah, I also think we should avoid depending on port-specific features. Not only would it result in non-portable code, but non-portable libraries, and then libraries based on those libraries will be non-portable and Shen becomes 10 different languages.
To unsubscribe from this group and stop receiving emails from it, send an email to qilang+unsubscribe@googlegroups.com.
If there is an official rule to not include new features to a port then we can get rid of the problem that Willi faced.
I think that if portability is the most important thing then we should not allow new features to be included in a port and it should be written in an official document that the porters can see to avoid further confusion.
For instance, in Shen-JVM there is a function called sj.println that I frequently use for debug purpose. Should I get rid of this and not include in the port?
The reason I included is that I frequently use this function and I am too lazy to load an external library when I open the REPL.
To unsubscribe from this group and stop receiving emails from it, send an email to qilang+unsubscribe@googlegroups.com.
Well its very important because that was the raison d'etre of Shen over Qi.If there is an official rule to not include new features to a port then we can get rid of the problem that Willi faced.
I think that if portability is the most important thing then we should not allow new features to be included in a port and it should be written in an official document that the porters can see to avoid further confusion.I'd agree with this. Bog standard programs like Willi's should not fail because of creative additions to the kernel. We (Willi and I) are going through all the ports systematically and we'll highlight what we find. Willi has some of the most comprehensive and complex Shen programs around.I think that adding new system functions to the kernel, however well-intentioned, should not be done. These things belong in a standard library. We have a good one in SP and I'm working on the financial side so as to be able to release it.
IMO you need an OS standard lib - much of this stuff would find a place in it. Then people can access it w.o. having Willi's problems. Any internal changes to the kernel for the sake of performance is fine. The SBCL stuff probably needs its own package sbcl.Basically the global namespace in the kernel should be kept clear for system functions that exist in the standard. Platform-specific extensions belong in platform-specific packages and extensions that are coded in Shen and generally useful for everybody belong in stlib. sterr may need thought.