Re: Breakthrough dream

[Sean Conner <sean@...>]

It was thus said that the Great Duane Leslie once stated:
> 
> Type annotations and optimisations would make the embedded compiler too
> large.  I think there is certainly merit in having an optimising compiler
> as a separate project, and it would be nice if it was supported by the
> core Lua team, but obviously they have their own priorities.  Essentially,
> we need a llvm compiler that takes Lua Source and outputs Lua ByteCode. 
> The only cooperation required from the core Lua team would be an agreement
> on some syntax that can be used for annotations which would be ignored by
> the embedded compiler.  This could be a marked up comment, but it would be
> nicer to have something separate.  I have some small annotations I use
> with a modified compiler and I use '<anno>'.  This could then integrate
> with LuaCheck and some DBC mechanism as well.  This solves (4).

  Okay.  I'll assume that Lua supports annotations, but ignores them.  Any
text between (and including) '@' is ignored.  Other tools could make use
such text.  Code might look like (pulling from some code I'm currently
working on):

	local function dis_fault(
		@type: userdata@ @luacheck: ignore 212@ dis,
		@type: integer@  @luacheck: ignore 212@ fault
	)
	  -- XXX to be done
	end

  It could be done now:

	local function dis_fault(
		--[[ type: userdata ]] --[[ luacheck: ignore 212 ]] dis,
		--[[ type: integer ]]  --[[ luacheck: ignore 212 ]] fault
	)
	  -- XXX to be done
	end

  I'm ambivalent.  I mean, this just means that '@...@' is another form of
comment and given that Lua will ignore it, I'm not sure if it serves the
proper role.  I'm thinking that the inline block comments is good enough. 
But I'm ambivalent enough to give this a +0.5.

  -spc