[erlang-questions] Pmods, packages, Unicode source code and column numbers in compiler - what will happen in R16?

freza@REDACTED freza@REDACTED
Fri Oct 19 20:03:11 CEST 2012


On Thu, Oct 18, 2012 at 06:09:39PM +0200, Richard Carlsson wrote:
> Those things could be fixed with a proper implementation. But the
> current OTP proposal is to keep only the crappy part of it, which
> makes very little sense to me.

Yeah, that "tuple module" thing is really bizarre... would be interesting
to hear the justification for keeping it (I mean, anything besides "provide
low-level hack that can be used to support pmods"?).

> And if you dislike parameterized modules, do you dislike funs as well?
> They're both just closures.

Not to sound needlessly confrontational, but this strikes me as a bit far
fetched.

First class functions have syntactic support in the language and cooperate
seemlessly with lexical scoping, all nice and no surprises. Parametrized
modules on the other hand have their environment filled in from outside by
an act of magic, distort function arities invisibly by introducing quite
weird calling convention, and you can't even call them closures because,
module being the toplevel scope, there just isn't anything to close over.
Oh, and module environments don't really support variables, just functions,
that's another strangeness.

If you argue these are unfortunate aspects of the implementation then I'd
be honestly curious to see what design is this implementation implementing
then, just so we're on the same page. Presumably the idea was to turn
modules into proper first class objects? That sounds like worthwhile
research effort (despite all the atrocities people managed to inflict
with pmods); it could be nice to be able to write small supervisors and
gen_servers "inline".

But can this be done without basically introducing syntax for an expression
that evaluates to module-thing, and which conforms to the usual lexical
scoping rules, similar I think to what 'object' stuff works like in OCaml?
Maybe I'm just lacking imagination to see other sensible approaches?

BR,
	-- Jachym



More information about the erlang-questions mailing list