(defun target-in-zone ('float 'float -> 'boolean)
...)
He has also proposed a guard-like syntax using the Irdis-inspired "so" ... (maybe "when" could be used instead?)--
You received this message because you are subscribed to the Google Groups "Lisp Flavoured Erlang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-e...@googlegroups.com.
To post to this group, send email to lisp-flavo...@googlegroups.com.
Visit this group at http://groups.google.com/group/lisp-flavoured-erlang.
For more options, visit https://groups.google.com/d/optout.
IIRC there was a question on twitter if it was more or less to implement putting the type spec information inside the function or keeping it outside. It makes no real difference. However, we do it makes no real difference as we still have to return two forms, one the function definition and the other the type information. We could actually have system where we allow both.
If we doit it inside the function definition then we have be a little sneaky. Using [ ] doesn't help as they are parsed exactly the same as ( ) so you don't see the difference after parsing, which is why they are optional. The problem inside the defun is making sure that it doesn't get mixed up with an argument list so defun gets it wrong. One way would be to only allow directly AFTER a documentation string:
(defun foo
"foo is really ... "
(type-of (integer integer) atom)
<match body> )
(defun foo (a b)
"foo is really ... "
(type-of (integer integer) atom)
<normal body> )
That would be easy and safe to implement but a bit restricted.
Another solution would be to make (type-of ...) a reserved form which always means the type specification of the function. Then you could have
(defun foo
(type-of (integer integer) atom)
<match body> )
(defun foo (a b)
(type-of (integer integer) atom)
<normal body> )
Or perhaps even ignore (type-of ...) completely when determining whether it is a normal function or a match function. type-of is mainly just for the examples and not something already decided.
These are my thoughts so far on the issue.
Robert
On Sunday, March 9, 2014 10:19:25 PM UTC-7, Sean Chalmers wrote:Hi Duncan,We'd need to differentiate it in someway from a normal fun form, otherwise the parser would never speak to me ever again. It's probably a bit silly of me to have used 'defun' like that in my examples but I prefer this method. Even if we have to use square braces or something instead of normal parenthesis. Or possibly a different macro name to signify that we're including a spec?(defunt target-in-zone ('float 'float -> 'boolean)...)or(defun target-in-zone ['float 'float -> 'boolean]...)I really really don't want to start introducing too much or any new syntax if I can avoid it. Apart from the signatures themselves, but even then keeping the lexicon tiny is a goal. I'm only really starting to drill into this in the last 18 hours, so I have a lot of hammocking to do. Expect more ! :DCheers,Sean
--
You received this message because you are subscribed to a topic in the Google Groups "Lisp Flavoured Erlang" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lisp-flavoured-erlang/lM3v9L3-A1M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to lisp-flavoured-e...@googlegroups.com.
Thanks Robert !
To unsubscribe from this group and all its topics, send an email to lisp-flavoured-erlang+unsub...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Lisp Flavoured Erlang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-e...@googlegroups.com.
You received this message because you are subscribed to a topic in the Google Groups "Lisp Flavoured Erlang" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lisp-flavoured-erlang/lM3v9L3-A1M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to lisp-flavoured-e...@googlegroups.com.
You received this message because you are subscribed to a topic in the Google Groups "Lisp Flavoured Erlang" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lisp-flavoured-erlang/lM3v9L3-A1M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to lisp-flavoured-e...@googlegroups.com.
Thanks mate, I really did just imitate that chapter so it’s less than it appears. :)It’s less of a deep types issue and more, “Would writing this function spec make me want to flip tables?”.I don’t see much too much in the way of new or scary syntax, but there are a couple. They’re only applicable for type definition, insofar as I am aware. But it’d be a bunch of work to implement it, I haven’t had a chance to produce something useable from all of that yet.I want to make a bunch of functions I can use to parse type signatures so we can at least get a feel for what it’s like to use them… Or macros.. Once I can get my head around slicing up the arguments to a macro without evaluating them…
You received this message because you are subscribed to a topic in the Google Groups "Lisp Flavoured Erlang" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lisp-flavoured-erlang/lM3v9L3-A1M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to lisp-flavoured-e...@googlegroups.com.
I hate to dig up an old thread like this, but what's the status of deftype and its ilk?I'm running into some difficult wrt types and such on the exercism track.
--
You received this message because you are subscribed to a topic in the Google Groups "Lisp Flavoured Erlang" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lisp-flavoured-erlang/lM3v9L3-A1M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to lisp-flavoured-e...@googlegroups.com.