Dialyzer and Crazy Ideas

144 views
Skip to first unread message

Sean Chalmers

unread,
Mar 9, 2014, 5:33:49 PM3/9/14
to lisp-flavo...@googlegroups.com
Hi everyone !

I just blogged a thing over here (http://mankykitty.github.io/lfe/2014/03/09/lfe-type-system.html) about my thoughts on including Dialyzer support in LFE. I'm aware it's not currently possible, but it apparently only requires a patch to OTP (https://twitter.com/nokusu/status/442679926932905984). Before work can really get underway ! Which is slightly terrifying as I was expecting to have ages to tinker with this behind the scenes. ;)

It seems I'm not the only one that would like to see this happen and in a fit of insanity I've also submitted a talk proposal to Erlang User Conference. Eeeeeeeep.

Would love to hear feedback about the idea so I can flesh this out into something more than just a late night blog post. :)

Cheers

Sean

Duncan McGreggor

unread,
Mar 10, 2014, 12:54:14 AM3/10/14
to lisp-flavo...@googlegroups.com
Robert,

This brings up the chat we had on the mail list a while back about spec support. Do you think it would be easier to use a (spec ...) form before a (defun ...), mirroring the Erlang way of doing this, or instead, to do what Sean has suggested in his blog post, something like this (something like this definitely has a syntactic appeal to me :-)):

(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?)

I won't paste the types and spec combo example, but I love that idea as well :-)

d



--
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.

Sean Chalmers

unread,
Mar 10, 2014, 1:19:25 AM3/10/14
to lisp-flavo...@googlegroups.com
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 ! :D


Cheers,

Sean

rvirding

unread,
Mar 10, 2014, 9:37:34 PM3/10/14
to lisp-flavo...@googlegroups.com
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

Duncan McGreggor

unread,
Mar 10, 2014, 11:32:39 PM3/10/14
to lisp-flavo...@googlegroups.com
On Mon, Mar 10, 2014 at 6:37 PM, rvirding <rvir...@gmail.com> wrote:
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> )

I like doing it inside the function, and your suggestion has a nice Lisp-y feel. The only question I have about this is for a match-body, the types would have to be the same for each match. Would it be possible/practical to match against different types?

If so, would it be possible to check the argument list, and if the last element was a (type-of ...) form, do type magic, and if not, do business as usual?

If possible, this would allow for flexibility in match-bodies ... but it's starting to look a little awkward:

(defun foo (a b (type-of (integer integer) atom))
  <normal body>)

(defun foo
  (( ... (type-of ...))
   ...)
 ...
  (( ... (type-of ...))
   ...))
 
 
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.

I like (type-of ...) :-) Whatever name we end up with for this form, I do hope it is named ;-) I prefer explicit over implicit (most of the times...).
 

These are my thoughts so far on the issue.

Thanks, Robert!

d

 

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 ! :D


Cheers,

Sean

--

Sean Chalmers

unread,
Mar 11, 2014, 12:27:20 AM3/11/14
to lisp-flavo...@googlegroups.com
Dialyzer doesn’t support multiple specs for a single function, even if different branches of the function take different arguments:

-spec(foody(atom()) -> string()).
-spec(foody(string()) -> atom()).
foody(something) ->
    "else";
foody("else") ->
    3.

Fails with
diademo.erl:20: spec for diademo:foody/1 already defined

So in all likelihood at this stage, for Dialyzer support at least, we would need to stick to one specification per function. The awesomeness of extra type-age (well I think it’s awesome. :P ) Might have to wait for now. 

I would like to keep the definition inside the function as well, although I would change the names for explicit type definitions to be consistent with Dialyzer since LFE tends to err on Erlang defaults for things. Names, Underscores, etc… My suggestion would be

'deftype(s)' or 'type-of' for module type definitions.

'spec-of', or even 'with-spec' for function definitions.

I’m down with the explicit naming though, that definitely makes it easier. :D

Cheers Robert & Duncan ! :D

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.

Sean Chalmers

unread,
Mar 12, 2014, 9:19:52 PM3/12/14
to lisp-flavo...@googlegroups.com
Hi All,

I’ve hacked out a couple of functions / macros that can take some of the ideas we’ve discussed and turn them into a data structure that should be able to easily be smooshed into a type or spec for Dialyzer.

Here there be monsters —> https://gist.github.com/mankyKitty/9519790

(Seriously, monsters… first draft warnings and all that).

This initial concept wouldn’t let me support some of the other things I wanted to do like different branches providing their own return types. Which DOES actually work with Dialyzer, I was just using it incorrectly. ><“ I can see how I want that feature to work and this particular hack won’t support it. But sooooooon. :D

Also I suspect the final form for these components will most likely be Erlang and not LFE? Although it would depend on where in the process it ends up.. I was hoping to build something that let you check types from within the REPL, though that might be more a Dialyzer change. </random thoughts>

Cheers !

Sean

Sean Chalmers

unread,
Mar 13, 2014, 5:45:53 AM3/13/14
to lisp-flavo...@googlegroups.com
@noksu pointed out some things on twitter like defining the types as a tree, and asking about functions with multiple specs (branches).  (https://twitter.com/nokusu/status/444036576696614913) (https://twitter.com/nokusu/status/444037439783723008) (https://twitter.com/nokusu/status/444037518594695168). Just posting it to the list so I don’t lose it.

This stuff is covered in Dialyzer, it supports it in it’s own way and I’ve been mulling about how to create them properly. It’s next on my list so I might just jump on it so we’ve got something to chew on. 

In order to support what I want to do for the multiple specs and proper encapsulation of the information I need, probably going to  follow the typed clojure annotation examples and wrap the functions we’re speccing in the spec definition.

So like:

(spec ‘int ‘float
(defun foo (a b)
…))

Which is no less lispy than the original idea, probably saves on fiddling with the parser a little. See how it goes. :) 

Messing with how I actually express the types themselves as well, since ‘-> is annoying to type.

Cheers everyone !!

Sean

rvirding

unread,
Mar 15, 2014, 10:10:42 PM3/15/14
to lisp-flavo...@googlegroups.com
Some more thoughts on the typing:

- A function can have multiple specs but you have to write them as alternatives in one spec. In erlang something like:

-spec foody(atom()) -> string() ;
      foody(string()) -> atom().


My thought in LFE would be to have this as multiple (type-of ) in the function (or before it) and merge them together in the compiler.

- Irrespective of what syntax we use what we generate in the end is fixed, it must be the exactly the same as the type declarations/specifications in erlang generate so that tools using them (dialyzer) can read it.

- My idea with the (type-of ) is that positionally it would be like the comment, outside of everything and beside the comment. Perhaps allow types in every clause but directly after the pattern.

- I haven't got as far as type declarations yet.

- We need a good way to specify a type. If we only allow type info and not variable names perhaps just an atom. A list could be either list or () for the general case and (atom) for a typed list. A tuple perhaps tuple or #() or #(atom number number). Just a first thought.

- I personally seldom use types, mainly just to keep the dialyzer quiet :-):

foo(atom()) -> no_return().

For now,

Robert

Sean Chalmers

unread,
Mar 16, 2014, 12:35:44 AM3/16/14
to lisp-flavo...@googlegroups.com
For the multiple specs I was hoping to have the specs directly after the pattern. So something like:

(defun foo
  ([(cons x xs)] (type-of (list 'atom) 'string)
   ...)
  ([foo (cons x xs)] (type-of 'integer (list ‘atom) ’my-type)
   ...))

That would then be pulled into the combined dialyzer acceptable definition as you said.

For the type definitions, it should just be an atom, so far as I know. Because it’s not really ‘variable’, once you’ve defined the type that’s it. Because like the specs, the type definitions have to be made into the Dialyzer acceptable version. The other thing with type definitions is you can define a function as a type. So :

-type foo() :: {atom(), float()}.
-type bar(A) :: fun(A) -> foo().

(deftypes
  'foo #('atom 'float)
  'bar (('any) 'foo))

I think I had something like that working on that gist I posted… kinda.. sorta >_>

I don’t really want to invent syntax or anything, so I think just using how we structure the lists of information should be sufficient. I was creating a list that was basically the Dialyzer statement. I broke it when I implemented something else but I could make that work again. It was close?

Types don’t seem to be a terribly high priority with a lot of the erlang community, and even with Lisp they’re not really a huge thing. So my excitement mostly comes from messing around with Haskell and Idris (which I highly recommend btw!). I’m trying to think about how I could build this sort of thing as a library within LFE that I could use to just check things as I went, or create a particular generic error type even. So not a compiler error since that’s not how it works, but something that could potentially be handled as things run, like any other kind of error. Maybe… I dunno.. thinking out loud. :) :)

Raoul Duke

unread,
Mar 17, 2014, 1:51:24 PM3/17/14
to lisp-flavo...@googlegroups.com
hi,

i am a bit confused here. is this / how is this intended to work with
dialyzer? i keep hearing that dialyzer doesn't work with non-erlang
syntax and that somebody from the "alternative syntax" community sub
culture must figure out and submit patches to the dialyzer team to get
it to the point where we can all get along? is that happening?
otherwise isn't all this pie in the sky? i'm just trying to understand
what-all would have to happen to make lfe even more copacetic with
dialyzer, that would be very exciting to me.

sincerely.

Sean Chalmers

unread,
Mar 17, 2014, 6:11:15 PM3/17/14
to lisp-flavo...@googlegroups.com
That’s one of the things that has to be sorted yeah. Except i think the change is that this sort of information needs, or many would prefer, that it’s stored in the compiled beam files. So there is a syntax or structure in Core Erlang that everyone can target, then that is stored in the beam files, then it’s available to whatever tools people can come up with.

There was a discussion on twitter about it… can’t remember if there was work already underway, or if was just discussions though. :( I’ve not investigated it too much either, I should probably have a crack at that..

Plenty of room for more pies in the sky if you want to join in! There’s a few of us that are pretty excited about this. :D

Cheers,

Sean

Raoul Duke

unread,
Mar 17, 2014, 6:23:42 PM3/17/14
to lisp-flavo...@googlegroups.com
> Plenty of room for more pies in the sky if you want to join in! There's a few of us that are pretty excited about this. :D

i'm excited too, especially since i will never have the time or brains
or energy to actually help *make* this happen but would love to *use*
it.

but i'm worried that it is all sorta moot if Dialyzer isn't patched,
through the appropriate patching process that the Dialyzer team wants
people to use. i'm worried that the social engineering isn't
happening, and will nullify these experiments.

rvirding

unread,
Mar 17, 2014, 6:29:55 PM3/17/14
to lisp-flavo...@googlegroups.com
Raould,

Today dialyzer gets its information in two ways:

- You either give an erlang .erl source file which it compiles down to Core erlang
- You give it a .beam file compiled with debug_info which then contains the erlang abstract syntax tree for the module, which it then compiles down to Core erlang

So dialyzer works at the Core erlang level. So one suggestion is to add a way to store the core erlang for a module in the beam file so dialyzer can/will use it. Another suggestion is to open up dialyzer to allow plugins for it to call to get the core form. Or both.

Both will then allow more languages to be used by dialyzer, not just those who compile to erlang, like LFE. When this is done it would also automatically allow dialyzer to check modules written in different languages.

It will happen, hopefully not too far in the future. Some pretty energetic people have expressed interest. I will start looking at the problem of generating type info before that so we are ready. It shouldn't be too difficult (famous last words) we "just" have to agree on a syntax for it in LFE.

We shall see,

Robert

Sean Chalmers

unread,
Mar 17, 2014, 6:38:52 PM3/17/14
to lisp-flavo...@googlegroups.com
Thanks Robert !

Famous last words indeed.. “How hard can it be?” heh. 

Do you know where/if I might be able to help out with the Erlang side of things?

If there are plenty of the right people looking at it already then I’ll keep poking around with some syntax ideas. Actually I might try create a more useful documentation for the syntax ideas.. We seem pretty consistent already to be honest, well I think so. :P

Cheers

Sean


rvirding

unread,
Mar 21, 2014, 9:42:06 PM3/21/14
to lisp-flavo...@googlegroups.com
What we definitely need is more examples, both the lfe repo and in the various repo Duncan is working on. Especially examples interfacing other packages written in Erlang either directly or maybe through a LFE library. And with some documentation too if possible. It doesn't have to be a long epistle, but something to help them get going.

That is what immediately came to mind. What do you prefer doing?

Robert
Thanks Robert !

To unsubscribe from this group and all its topics, send an email to lisp-flavoured-erlang+unsub...@googlegroups.com.

Sean Chalmers

unread,
Mar 21, 2014, 10:24:05 PM3/21/14
to lisp-flavo...@googlegroups.com
I'll write up more examples ! My head has more been in Haskell/Idris of late so I'm thinking more in types than Erlang. 

To check though, are you referring to examples of how we'd use the types in LFE, like a library that has types that works atop an existing library? 
(with documentation as to what is going on). 

Researching, documenting, and prototyping is mostly what I'm good at. :) (thanks uni !)

Sean

---

Duncan McGreggor

unread,
Mar 21, 2014, 11:53:59 PM3/21/14
to lisp-flavo...@googlegroups.com
One of the things that I like to see with type demonstrations is short examples without type info, and then that same example rewritten/refactored *with* types. Simple little functions, etc.

I wouldn't mind this chapter rewritten for LFE to use a proposed type syntax:
  http://learnyousomeerlang.com/dialyzer

We could treat it as a living doc, updating as we refine/tune the syntax...

Additional inspiration:
 *  https://github.com/clojure/core.typed/wiki/User-Guide
 * http://www.haskell.org/tutorial/goodies.html
 * http://learnyouahaskell.com/types-and-typeclasses

d



--
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.

Sean Chalmers

unread,
Mar 21, 2014, 11:57:14 PM3/21/14
to lisp-flavo...@googlegroups.com
That’s exactly what I just started doing… Creepy! 

-- 
Sean Chalmers
Sent with Airmail
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.

Duncan McGreggor

unread,
Mar 22, 2014, 12:01:43 AM3/22/14
to lisp-flavo...@googlegroups.com
Woo-hoo!

/me high-fives Sean

d

Sean Chalmers

unread,
Mar 22, 2014, 8:32:45 PM3/22/14
to lisp-flavo...@googlegroups.com
First stabs : https://github.com/mankyKitty/typed-lfe/blob/master/doc/lys_lfe_dialyzer.md

Basically working almost verbatim with the LYSE chapter on Dialyzer and type definitions. About to start the Functions section, but keen to hear feedback, corrections, ideas, or pointing out and horribly embarrassing errors I might have made. :)

I need a break to go checkout all the posts on Maps.. O.o damn, Duncan... 

Duncan McGreggor

unread,
Mar 22, 2014, 8:59:03 PM3/22/14
to lisp-flavo...@googlegroups.com
Wow, that's a *lot* of work!

Looking good, man... nothing jumps out (but I'm not a deep types guy, so I don't know that it would...)

Can't wait to start playing with this stuff :-)

d



Sean Chalmers

unread,
Mar 22, 2014, 9:10:18 PM3/22/14
to lisp-flavo...@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… 
-- 
Sean Chalmers
Sent with Airmail

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.

Duncan McGreggor

unread,
Mar 22, 2014, 9:31:53 PM3/22/14
to lisp-flavo...@googlegroups.com
On Sat, Mar 22, 2014 at 8:10 PM, Sean Chalmers <sclhi...@gmail.com> wrote:
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… 

There's a super-simple one here (deftest) that may get you started in the right direction:
  https://github.com/lfe/lfeunit/blob/master/include/lfeunit-macros.lfe#L16

Also, I've recently found Tim Dysinger's LFE macros from a few years back, and they're brilliant:
  https://github.com/lfe/lfesl/tree/master/include

Hth!

d

rvirding

unread,
Mar 22, 2014, 10:26:46 PM3/22/14
to lisp-flavo...@googlegroups.com
A few thoughts:

- Don't steal too much from the chapter, it will give a bad conscience. :-) And Fred's chapter is much longer than we need to be. At least for now.

- I think need 2 type "forms", one to define a type and one to specify the type of a function (clause). I chose (type-of ...) the for the second case. While that name sort of fits for a function we should use something else for defining types, deftype? Whatever we choose the names should be different.

- There is no real rush as we cannot use dialyzer to check types yet. There are as yet no hooks to allow it to get our type info. Either we have to fix dialyzer to use plugins or we have to get Core erlang into the beam file in the same way as for the Erlang AST, which is what debug_info does. Or both.

Fred Hebert

unread,
Mar 22, 2014, 10:36:36 PM3/22/14
to lisp-flavo...@googlegroups.com
I don't mind my chapter being used, but I'd consider being aware of
potential copyright issues that could be had with No Starch Press (the
LYSE publisher). I can't imagine them suing anyone, but you never know.

I also found an inconsistency:

-type tree() :: {'node', 'nil'}
| {'node', Left::tree(), Value::any(), Right::tree()}.

Is being compared to:

(type-of tree '('nil
#{'|node| (:: Left tree) (:: Value any) (:: Right tree)}))

But it should be:

(type-of tree '(#{'|node| '|nil|}
#{'|node| (:: Left tree) (:: Value any) (:: Right tree)}))

Unless you forgot to define the 'nil type as #{'|node| '|nil|} as far as
I can tell from your own document.

Regards,
Fred.

On 03/22, rvirding wrote:
> A few thoughts:
>
> - Don't steal too much from the chapter, it will give a bad conscience. :-)
> And Fred's chapter is much longer than we need to be. At least for now.
>
> - I think need 2 type "forms", one to define a type and one to specify the
> type of a function (clause). I chose (type-of ...) the for the second case.
> While that name sort of fits for a function we should use something else
> for defining types, deftype? Whatever we choose the names should be
> different.
>
> - There is no real rush as we cannot use dialyzer to check types yet. There
> are as yet no hooks to allow it to get our type info. Either we have to fix
> dialyzer to use plugins or we have to get Core erlang into the beam file in
> the same way as for the Erlang AST, which is what debug_info does. Or both.
>
> On Sunday, March 23, 2014 2:31:53 AM UTC+1, Duncan McGreggor wrote:
> >
> >
> > On Sat, Mar 22, 2014 at 8:10 PM, Sean Chalmers <sclhi...@gmail.com<javascript:>
> > > wrote:
> >
> >> 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…
> >>
> >
> > There's a super-simple one here (deftest) that may get you started in the
> > right direction:
> >
> > https://github.com/lfe/lfeunit/blob/master/include/lfeunit-macros.lfe#L16
> >
> > Also, I've recently found Tim Dysinger's LFE macros from a few years back,
> > and they're brilliant:
> > https://github.com/lfe/lfesl/tree/master/include
> >
> > Hth!
> >
> > d
> >
>
>

Sean Chalmers

unread,
Mar 23, 2014, 12:04:45 AM3/23/14
to lisp-flavo...@googlegroups.com
Holy crap I didn’t even consider this, oh geez that’s embarrassing! Thanks for letting me use your chapter, I should have asked yourself and No Starch Press first. Sorry about that. :(

I’ll drop them a line and see what they say, just to be sure. 

Yes that is an inconsistency, I was getting ahead of myself. Cheers !

-- 
Sean Chalmers
Sent with Airmail

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.

Sean Chalmers

unread,
Mar 23, 2014, 12:28:26 AM3/23/14
to lisp-flavo...@googlegroups.com
Thanks Robert, I tend to get carried away. It’s just so much FUN. :P

I’ll just get the Functions section done, tidy it up a bit, and have a crack at the actual definition functions with debug_info if I get that far. :)

-- 
Sean Chalmers
Sent with Airmail

rvirding

unread,
Mar 23, 2014, 1:00:35 PM3/23/14
to lisp-flavo...@googlegroups.com
Fred has given his approval so I am not worried. :-) I just meant that a lot of the discussion in LYSE is beyond what need now and we can always refer to it.

The problem for LFE is that the debug_info is not interesting as it will not be the way we get the type info into dialyzer. The LFE compiler never generates the erlang AST which is what debug_info adds to the beam file and dialyzer uses. It goes in at a later stage in the compilation process at the Core stage.

erlang AST -> pre expansion (AST) -> core erlang -> kernel erlang -> life time analysis (kernel) -> BEAM assembler

So we either have to add an option to the compiler to get it to add the core pass and modify dialyzer to use that, or fix dialyzer to to use LFE source files, or both. I have an idea of how we may be to hack this.

Robert

José Valim

unread,
Apr 2, 2014, 1:21:42 PM4/2/14
to lisp-flavo...@googlegroups.com
I am jumping in because this discussion affects Elixir too. :)

I am planning to submit patches to OTP and dialyzer. The goal is to come up with an official place to store Core Erlang AST in BEAM files and have dialyzer read from such places as part of the process Robert described. Storing it in the BEAM file is the best approach imo because other tools like concuerror can just read from it too.

The issue is that some engineers at OTP do not seem to enjoy this particular solution and they would rather prefer a plugin system for dialyzer... which I don't like exactly because we would need to devise a plugin system for each tool.

That said I am waiting for R17 to be out and start a discussion with the OTP team so we can reach an agreement and start working on those patches.

Raoul Duke

unread,
Apr 2, 2014, 3:32:25 PM4/2/14
to lisp-flavo...@googlegroups.com
> That said I am waiting for R17 to be out and start a discussion with the OTP
> team so we can reach an agreement and start working on those patches.
>
> On Sunday, March 23, 2014 6:00:35 PM UTC+1, Robert Virding wrote:
>>
>> Fred has given his approval so I am not worried. :-) I just meant that a
>> lot of the discussion in LYSE is beyond what need now and we can always
>> refer to it.
>>
>> The problem for LFE is that the debug_info is not interesting as it will
>> not be the way we get the type info into dialyzer. The LFE compiler never
>> generates the erlang AST which is what debug_info adds to the beam file and
>> dialyzer uses. It goes in at a later stage in the compilation process at the
>> Core stage.
>>
>> erlang AST -> pre expansion (AST) -> core erlang -> kernel erlang -> life
>> time analysis (kernel) -> BEAM assembler
>>
>> So we either have to add an option to the compiler to get it to add the
>> core pass and modify dialyzer to use that, or fix dialyzer to to use LFE
>> source files, or both. I have an idea of how we may be to hack this.
>>
>> Robert
>>

Raoul Duke

unread,
Apr 2, 2014, 3:33:09 PM4/2/14
to lisp-flavo...@googlegroups.com
ok that sucked, sent before i meant to by accident.

just wanted to say this is exciting to hear :-)

Eric Bailey

unread,
Jul 27, 2015, 1:33:44 AM7/27/15
to Lisp Flavoured Erlang, rao...@gmail.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.

Sean Chalmers

unread,
Jul 27, 2015, 1:42:09 AM7/27/15
to Lisp Flavoured Erlang, rao...@gmail.com
I don't know what other work has been undertaken, but I haven't touched this for quite some time. Sorry to say the status 'on life support in a very nice hospital'. :<

Sorry mate, there are probably other people that have had more success than me. :) :)

On Mon, 27 Jul 2015 at 15:33 Eric Bailey <ifsixw...@gmail.com> wrote:
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.

Robert Virding

unread,
Jul 27, 2015, 6:26:33 AM7/27/15
to Lisp Flavoured Erlang, sclhi...@gmail.com, rao...@gmail.com, sclhi...@gmail.com
There is more about this in this topic https://groups.google.com/d/topic/lisp-flavoured-erlang/gtfgZSFcZzU/discussion . In https://github.com/rvirding/lfe there is the 'dev-dialyzer' branch which contains the ldialyzer command which works but I need to merge in the latest from 'develop'. If people like this then I will include it as standard.

There has been talk of extending the erlang compiler so it can include the core erlang code in the .beam file and extending dialyzer to take its data from that. But I personally think generally cleaning up the dialyzer API would be better a choice, it is not something I would show to students as an example of good code.

Robert
Reply all
Reply to author
Forward
0 new messages