Name generation strategy of c.freshName

[Eugene Burmako]

It has just occurred to me that c.freshName in its current
implementation [1] isn't really fit for gensym purposes, because it:
a) only generates unique suffixes, but doesn't guarantee that produced
names don't clash with other names, b) only ensures uniqueness within
the current compilation unit, not application-wide.

Therefore I suggest we discuss the optimal name generation strategy
and change [1] to accommodate the results of the dicsussion.

[1]
https://github.com/scalamacros/kepler/blob/ab2d5fae278ca01a70d29f4255224a7103c6fb7f/src/compiler/scala/reflect/macros/runtime/Names.scala#L7

[Eugene Burmako]

Tbh I cannot think of anything better than java.util.UUID.randomUUID.

After debugging leaks in compiler caches I don't really fancy putting
up compiler-wide caches to remember unique names. Also something like
current c.freshName, but compiler-wide still doesn't solve the problem
of name clashes. If we do just c.freshName("Test"), then it will
happily return "Test1", which isn't that unreasonable of a name. If we
append some crazy unique suffix like "$$dollarfresh$", it still won't
help in general case.

The downsides of using uuids are: 1) pollution of output classpath in
case of incremental compilation (but, on the other hand, if you care
about pollution, why are you using fresh?), 2) ugly names.

On Dec 23, 2:21 pm, Eugene Burmako <eugene.burm...@epfl.ch> wrote:
> It has just occurred to me that c.freshName in its current
> implementation [1] isn't really fit for gensym purposes, because it:
> a) only generates unique suffixes, but doesn't guarantee that produced
> names don't clash with other names, b) only ensures uniqueness within
> the current compilation unit, not application-wide.
>
> Therefore I suggest we discuss the optimal name generation strategy
> and change [1] to accommodate the results of the dicsussion.
>

> [1]https://github.com/scalamacros/kepler/blob/ab2d5fae278ca01a70d29f4255...

[Rex Kerr]

It doesn't take very many UUIDs to have absurdly long generated names.  Can you try something more compact, like

  BigInt(129, scala.util.Random).abs.toString(36)  // 25 chars long usually

or if you want it to be a valid identifier,

  def r(i: Int) = scala.util.Random.nextInt(i)

  (r(26) :: List.fill(21)(r(62))).map{ i => i + (if (i<26) 'a' else if (i<52) 'A'-26 else '0'-52) }.
    map(_.toChar).mkString

which gives you 129.7 bits of randomness in a guaranteed 22-digit identifier.  (UUIDs as normally printed without dashes still use 32 digits to give 128 bits.)  Also, if you decide 128 bits is overkill, you can just adjust the length of the list (collisions go as number-of-names-squared, and you probably don't have more than 31 bits of names, or 62 bits of possible collisions; if you want that to happen no more than one time in a billion you only need around 92 bits, for which a 16-character string (1 + 15) is adequate).

  --Rex

[Paul Butcher]

Personally speaking, having something that's unlikely to clash (as opposed to guaranteed not to clash) gives me the willies.

I know that the chances we're talking about here are tiny, but I can't believe that having actually guaranteed uniqueness is that hard. Lisp has been doing it for years, after all :-)

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: pa...@paulbutcher.com
AIM: paulrabutcher
Skype: paulrabutcher

[Rex Kerr]

Guaranteed non-clashing is harder than unlikely clashing: you are required to observe the entire scope of the project.  For method names, it's not so hard: you already have your class, which must be unique (when the full package path is included), so you just look locally and fix it.  If you're trying to generate a type name which is unique but where you aren't sure who else might also be trying to generate unique names, your only recourses are randomness or an oracle.  If you knew that compilation was going to be serial and on the same machine, a nanoTime timestamp would do the trick (UUID type 1-style) for an oracle.

Ultimately, with large numbers of bits of randomness, one is likely to run afoul of having too little input randomness before one's random number generator isn't good enough.  So if one can encode some sort of path-dependent usually-unique information into part of your "random" identifier, you're probably better off.

Alternatively, you could just require: if you are going to compile A and B both of which put type names into the same namespace, you must not do it independently if you want to guarantee non-collision.  Do one at a time and put the other on the classpath, or do both in one compilation run.  Maybe that's the more sensible way to do it, and then just a hint of randomness to save you when you fail to do that is all that's needed (maybe six characters based on the low bits of nanoTime).

  --Rex

[Paul Phillips]

On Sunday, December 23, 2012, Eugene Burmako wrote:

Therefore I suggest we discuss the optimal name generation strategy
and change [1] to accommodate the results of the dicsussion.

We already fail to generate unique names even in the same compilation unit (that's why I said it is "guaranteed" to be unique, emphasis on the quotes) and we stand to do worse here.

For correctness to survive the ravages of the compiler, we need synthetic names to be "late bound" - the name needs identity, to experience the same transformations as the entity to which it is bound. It needs to know what it was composed from so that composition can be deconstructed when necessary. The name should never be a string - a string is what something else creates from the name. This is in contrast to the current situation, where:

 - the name is always a string, and never anything but a string

 - the name-string attempts to encode (lossily) a sequence of smaller name-strings

 - neither the subnames nor even the boundaries can be reliably reconstructed

 - many entities are recognized (when we're lucky) by unreliable sub-name-string matching

 - all of it interacts horribly with java reflection, which uses the same sub-name-string delimiter with stricter requirements

I shudder at the thought of any attempt to layer more logic on top of it. I would endorse some kind of random name generation if only because it stands the best chance of working and the least chance of making things worse. But if you want something better than a random string you have to go after naming itself, not just try to cobble a gensym on top of what is there.

[Rex Kerr]

On Sun, Dec 23, 2012 at 12:15 PM, Paul Phillips <pa...@improving.org> wrote:

On Sunday, December 23, 2012, Eugene Burmako wrote:

Therefore I suggest we discuss the optimal name generation strategy
and change [1] to accommodate the results of the dicsussion.

We already fail to generate unique names even in the same compilation unit (that's why I said it is "guaranteed" to be unique, emphasis on the quotes) and we stand to do worse here.

For correctness to survive the ravages of the compiler, we need synthetic names to be "late bound" - the name needs identity, to experience the same transformations as the entity to which it is bound.

Er, why then is not the name _the entity itself_?  That guarantees binding.

 

It needs to know what it was composed from so that composition can be deconstructed when necessary.

Do all entities know what they're composed from sufficiently well so that this condition is met?  If not, it seems that this information should be added.

 

The name should never be a string - a string is what something else creates from the name.

That's fine, but you still have the collision problem on generated strings.  And you have the problem of how to find out

  class X {

    class Y {

      class Z {

        object W {  // What am I called?

          def v = List(2,3,4).map(_ + 1)   // What is the anon function called?

        }
      }
    }
  }

with java (and javap and the like) if you don't do string-name-mangling as part of the generation process, at least.  I rely currently on these things being named in a semi-predictable fashion.  Given that I can't run a high-quality hash function in my head (especially not in reverse), non-colliding but undecipherable strings are only slightly better than possibly-but-very-rarely-colliding decipherable strings.

 

This is in contrast to the current situation, where:

 - the name is always a string, and never anything but a string

 - the name-string attempts to encode (lossily) a sequence of smaller name-strings

 - neither the subnames nor even the boundaries can be reliably reconstructed

Well, this is not so hard.  Any quoting system can fix the issue here.

For example, suppose we allow $ in regular names but not in sequences, and make $$ our "sequence here!" symbol.  Then going forwards we just

  def encode(ss: String*) = {

    val sb = new StringBuilder

    ss.map{ s =>

      sb.clear

      var i = 0

      while (i < s.length ) {

        s(i) match {

          case '$' => sb ++= "_$"

          case '|' => sb ++= "_|"

          case '_' => sb ++= "__"

          case c => sb += c
        }

        i += 1
      }

      sb.result

    }.mkString("||")

  }

and going backwards when we find $$ we seek to the next $$, clip out the intervening string, and

  def decode(s: String): Array[String] = {

    if (s.isEmpty) return Array[String]()

    def fail = throw new IllegalArgumentException("Malformatted encoded string "+s)

    val ssb = Array.newBuilder[String]

    val sb = new StringBuilder

    var i = 0

    while (i < s.length) {

      val c = s(i)

      if (c=='|') {

        if (i+1 >= s.length || s(i+1) != '|') fail

        ssb += sb.result

        sb.clear

        i += 1
      }

      else if (c=='_') {

        if (i+1 >= s.length) fail

        val q = s(i+1)

        q match {

          case '$' | '_' | '|' => sb += q; i += 1

          case _ => fail

        }
      }

      else sb += c

      i += 1
    }

    ssb += sb.result

    ssb.result

  }

(I've written these in high-performance mode in case you actually want to use them.)

If you want heavily-nested quoting, you need a different strategy, e.g. where $n is your quote character, so you can reduce the amount of escaping.

Anyway, there are many strategies like this that work well and are easy enough to implement.

If you tell me more precisely what the compactness and nesting requirements are, I'll come up with a different nestable encode-decode pair for you, if you'd like.  (I think these two work, though I've only tested sparingly.)

  --Rex

[Paul Phillips]

Not to dispute the theoretical validity of your suggestions, but I don't think you appreciate what you're up against in the compiler. The essential difficulty is not one of identifying a better way, but of getting from here to there.

On Sun, Dec 23, 2012 at 10:43 AM, Rex Kerr <ich...@gmail.com> wrote:

Er, why then is not the name _the entity itself_?  That guarantees binding.

I didn't intend my phrasing to exclude that possibility; "the name" was intended to imply a sufficiently abstract representation as to enclose the thing itself. That said, it cannot be the entity itself as things presently work because the entity itself is forgetful - names are often based on enclosing constructs, which change (destructively, even) over the course of compilation. Names also can depend on information which cannot be reconstructed, such as when symbols are cloned and have no type history from before the cloning took place.

Do all entities know what they're composed from sufficiently well so that this condition is met?  If not, it seems that this information should be added.

Much of what is presently not accessible without reconstruction is as it is for performance reasons. How valid those reasons are I can't say; that this factor complicates any attempt to modify things I can say.

 

That's fine, but you still have the collision problem on generated strings.  And you have the problem of how to find out

  class X {

    class Y {

      class Z {

        object W {  // What am I called?

          def v = List(2,3,4).map(_ + 1)   // What is the anon function called?

        }
      }
    }
  }

The requirement to derive names for those things exists in the current scenario as well as any other; I don't see the relevance.

with java (and javap and the like) if you don't do string-name-mangling as part of the generation process, at least.

I never intended to suggest these things never acquire string names. You can't generate bytecode without naming them. I'm saying we have to defer the string generation until the end, not to let strings work their way through thirty phases of compiler logic.

Well, this is not so hard.  Any quoting system can fix the issue here.

 

For example, suppose we allow $ in regular names but not in sequences, and make $$ our "sequence here!" symbol.

You've already irreparably broken java reflection. I don't mean "it doesn't reflect scala semantics", I mean e.g. "calling getSimpleName throws a 'Malformed class name' exception" and so on. I know how to quote things in theory. What is needed here is practice. The things which work have to keep working.

Here are some things already in use:

  ending with a $ (module classes)

  operator translation: '+' becomes $plus

  as a separator: $$

  as ad hoc separators like $_setter_$

  as even longer separators like $$$$

Here are some tickets:

  https://issues.scala-lang.org/browse/SI-2806

  "Name mangling has outstripped the abilities of lonesome '$'''

  https://issues.scala-lang.org/browse/SI-3623

  "name mangling is hitting hard path length limits"

  https://issues.scala-lang.org/browse/SI-4316

  "name mangling vs. java reflection"

  https://issues.scala-lang.org/browse/SI-4023

  "getDeclaredClasses seems to miss some (REPL) or all (scalac) classes (objects) declared"

Then there are a whole bunch linked here, many of which involve mangling for access reasons:

  https://issues.scala-lang.org/browse/SI-6794

  "Can we please reach some kind of decision on access"

Then there are lots of closed ones, some wontfix.

Here is an abbreviated selection of semantically significant subnames utilizing '$'.

val BITMAP_PREFIX                     = "bitmap$"

val CHECK_IF_REFUTABLE_STRING         = "check$ifrefutable$"

val DEFAULT_GETTER_INIT_STRING        = "$lessinit$greater" // CONSTRUCTOR.encoded, less is more

val DEFAULT_GETTER_STRING             = "$default$"

val DO_WHILE_PREFIX                   = "doWhile$"

val EQEQ_LOCAL_VAR: NameType          = "eqEqTemp$"

val EVIDENCE_PARAM_PREFIX             = "evidence$"

val EXPAND_SEPARATOR_STRING           = "$$"

val FAKE_LOCAL_THIS: NameType         = "this$"

val INTERPRETER_IMPORT_WRAPPER        = "$iw"

val LAZY_LOCAL: NameType              = "$lzy"

val LAZY_SLOW_SUFFIX: NameType        = "$lzycompute"

val MIXIN_CONSTRUCTOR: NameType       = "$init$"

val MODULE_INSTANCE_FIELD: NameType   = NameTransformer.MODULE_INSTANCE_NAME  // "MODULE$"

val OUTER: NameType                   = "$outer"

val PROTECTED_PREFIX                  = "protected$"

val REIFY_FREE_PREFIX: NameType       = "free$"

val REIFY_FREE_THIS_SUFFIX: NameType  = "$this"

val REIFY_FREE_VALUE_SUFFIX: NameType = "$value"

val REIFY_SYMDEF_PREFIX: NameType     = "symdef$"

val SUPER_PREFIX_STRING               = "super$"

val TRAIT_SETTER_SEPARATOR_STRING     = "$_setter_$"

[Rex Kerr]

On Mon, Dec 24, 2012 at 3:55 PM, Paul Phillips <pa...@improving.org> wrote:

Not to dispute the theoretical validity of your suggestions, but I don't think you appreciate what you're up against in the compiler.

You're quite right, of course.

 

The essential difficulty is not one of identifying a better way, but of getting from here to there.

Is it really that easy--just identifying the path?  That makes it sound like one could just envision a consistent naming scheme and replace all the offending bits in one swoop, yielding something compact and quotable.  It's a horribly breaking breaking change for Java interop, but if the alternative is not working, even with Java, it might be worth it.  More worth it earlier rather than later.  Scala usage still seems to be going up.

But if one is not allowed to make a breaking change then there is no possible way to get from here to there since here requires broken stuff, and there is not supposed to have any.

 

On Sun, Dec 23, 2012 at 10:43 AM, Rex Kerr <ich...@gmail.com> wrote:

Er, why then is not the name _the entity itself_?  That guarantees binding.

I didn't intend my phrasing to exclude that possibility; "the name" was intended to imply a sufficiently abstract representation as to enclose the thing itself. That said, it cannot be the entity itself as things presently work because the entity itself is forgetful - names are often based on enclosing constructs, which change (destructively, even) over the course of compilation. Names also can depend on information which cannot be reconstructed, such as when symbols are cloned and have no type history from before the cloning took place.

This sounds to me like an argument for entities to remember where they came from, or for entities to not know their own name (so that you can discard the name to save space).  Knowing where you came from is extremely useful for incremental compilation also, as you are only a few steps away from a (detailed) dependency graph.  I'm not suggesting that this is a feasible reworking; just that it would be nice.  Maybe steps in that direction pay dividends even before you reach completeness?

 

Do all entities know what they're composed from sufficiently well so that this condition is met?  If not, it seems that this information should be added.

Much of what is presently not accessible without reconstruction is as it is for performance reasons. How valid those reasons are I can't say; that this factor complicates any attempt to modify things I can say.

Throwing away reasoning seems sensible.  Throwing away what was reasoned seems less obviously wise (which includes who-you-are-and-why).  I wonder whether there is a clear distinction.

 

 

Well, this is not so hard.  Any quoting system can fix the issue here.

 

For example, suppose we allow $ in regular names but not in sequences, and make $$ our "sequence here!" symbol.

You've already irreparably broken java reflection. I don't mean "it doesn't reflect scala semantics", I mean e.g. "calling getSimpleName throws a 'Malformed class name' exception" and so on.

Er, well, some cases are quite broken, yes.  (Aren't they already, though?  I haven't proposed anything you can't already find in a class name anyway.)  One could mangle with underscores instead of dollars, which at least should render everything well-formed, if pretty incomprehensible from Java.

 

I know how to quote things in theory. What is needed here is practice. The things which work have to keep working.

[Snipped examples.]

Well, I suppose the first thing to do would be to decide if the whole encoding-path-in-string thing is something to play along with or discard.  If yes, come up with a compact consistent quotable representation and fell-swoop a change.  If no, hello drawing-board!

But I am out of my depth here--to help meaningfully anyway, at this point--so I will instead just say thank-you for the educational details, and maybe I'll stop assuming theoretically sensible things are close enough to practice to be worth mentioning.  Instead, I'll try to check practice out first.

  --Rex

 

[Simon Ochsenreither]

Not really related to the specific naming issues at hand, but wouldn't adopting the JVM's recommended name mangling reduce the need for mangling in the first place and even eliminating it completely in most let's-mangle-symbolic-method-names cases?
Benefits would be that stacktraces and other parts involved with bytecode would get a lot more readable.

The only change I see is that calling those methods from Java would get harder, although I can't think of a library who made use of the fact that Java people can call $bang, $plus$plus and friends today.

Imho we're stuck with a less than optimal compromise currently. If a library needs to be accessible from Java, library authors write more easily usable method names/APIs anyway (see Akka) instead of telling people to go ahead and use the dollar-names. Either embrace that or emit Java-compatible forwarders by default, but all this $stuff doesn't buy us much here, imho.

Sorry, it's kind of off-topic to the actual issues at hand, but just remembered it.

[Rex Kerr]

On Mon, Dec 24, 2012 at 7:39 PM, Rex Kerr <ich...@gmail.com> wrote:

On Mon, Dec 24, 2012 at 3:55 PM, Paul Phillips <pa...@improving.org> wrote:

You've already irreparably broken java reflection. I don't mean "it doesn't reflect scala semantics", I mean e.g. "calling getSimpleName throws a 'Malformed class name' exception" and so on.

Crikey, yes, of course I did.  I used a | symbol.  I can't recall what I was thinking.  I know those don't belong in class names.  Oops!

  --Rex

 

[Paul Phillips]

On Tue, Dec 25, 2012 at 9:31 AM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

Not really related to the specific naming issues at hand, but wouldn't adopting the JVM's recommended name mangling reduce the need for mangling in the first place and even eliminating it completely in most let's-mangle-symbolic-method-names cases?

Yes, this is what I would like to do, with the caveat that as far as I know the "jvm recommended name mangling" is purely a theoretical exercise. You're talking about this[1], yes? Not that john rose wouldn't know what he's talking about, but this was written 4+ years ago, and is there any language putting it into practice? If we are the first there will be arrows to take, maybe poison-tipped ones.

[1] https://blogs.oracle.com/jrose/entry/symbolic_freedom_in_the_vm

[Simon Ochsenreither]

Yes, I meant John Rose's text, forgot to mention it. Sorry for that. As far as I remember JRuby did something related to it, experienced a few problems with ASM being too strict and got it fixed a while ago.

Ah, here, found at least one hint: http://jira.codehaus.org/browse/JRUBY-5225

Are we still exposing the mangling scheme in the reflection/macro API? I remember that some people voiced concerns about it and this situation is like one of the main reasons why it is a bad idea.

[Simon Ochsenreither]

Btw, is this expected behaviour?

scala> val / = 1
/: Int = 1

scala> var / = 1
/: Int = 1

scala> def / = 1
$div: Int

[Rex Kerr]

Is there any point considering mangling with _, which would yield all mangled names accessible to Java and would avoid all issues with $ parsing?  One wouldn't necessarily need to make strings absurdly long to mangle that way; ___ doesn't appear at all within an identifier name (as far as I can tell with a quick grep-like search), nor do

    i_ j_ z_ Z_ _k _z _Q _Y

which make those or things like them tempting quote targets.  Alternatively (weirdly) one could pick other two-letter combinations as a quote pair.  Here are the ones that do not appear--plenty to choose from.  (If doing this, one should of course scan a larger set of files than just the compiler; some of these appear in code I've written, for instance.)

aJ aQ aY aZ bh bk bq bw bz bH bJ bK bQ bW bX bY bZ cj cz cJ cK cQ cY cZ dz
eY fk fq fw fx fz fJ fX fY fZ gj gk gq gx gJ gZ hf hg hh hj hn hq hw hx hz
hX hY ih iw iy iD iG iH iJ iK iM iN iO iQ iU iV iW iX iY iZ jg jh jj jk jq
jr jw jx jy jz jD jF jG jH jI jJ jK jL jM jN jQ jR jV jW jX jY jZ kd kj kx
kz kY lg lq lX lY lZ mj mq mw mx mz mQ mY mZ nY oh oq oY oZ pj pq px pY pZ
qb qc qd qf qg qh qj qk ql qm qo qw qx qy qz qB qG qJ qK qQ qU qX qY qZ rj
rx rz rX sj sv sY tj tk tz uh uj uk uq uv uy uz uA uC uD uE uF uG uH uI uJ
uL uM uN uO uP uQ uR uS uT uU uV uW uX uY uZ vc vh vj vk vr vu vw vx vz vH
vJ vK vQ vU vV vW vX vY vZ wb wg wj wk wq wv ww wx wy wz wK wQ wX wY xb xf
xg xj xk xl xq xr xv xw xz xK xX xY xZ yg yh yj yk yq yY yZ zb zd zf zg zh
zj zk zl zm zn zp zq zr zt zu zv zw zx zA zC zD zE zG zH zI zJ zK zL zO zP
zQ zR zS zU zV zW zX zY zZ Aa Ae Ai Ak Ao Aq Ax Ay Az AA AF AH AO AQ AW Bb
Bc Bd Bh Bj Bk Bm Bq Bt Bv Bw Bx Bz BC BH BK BM BQ BV BW BX BZ Cb Cc Cf Cj
Cq Cs Cv Cx Cz CF CQ CV CW CX Db Dd Df Dg Dh Dj Dl Dm Dn Dq Ds Dv Dw Dx Dz
DH DJ DK DM DP DQ DW DX DZ Eb Ee Eg Eh Ej Ew Ey Ez EH EJ EK EU EZ Fb Fc Fd
Ff Fg Fh Fp Fq Fv Fw Fx Fy Fz FG FH FJ FK FQ FV FW FX FY FZ Gb Gc Gd Gf Gg
Gh Gi Gj Gm Gn Gp Gq Gs Gt Gv Gw Gx Gy Gz GB GD GF GG GH GJ GK GM GQ GU GW
GX GY GZ Hb Hc Hd Hf Hg Hh Hj Hl Hm Hn Hp Hq Hs Hu Hv Hw Hx Hz HB HC HD HF
HJ HN HP HQ HV HW HX HY HZ Ia Ib Ie Ih Ii Ij Ik Ip Iq Iu Iv Iw Ix Iy Iz IH
IK IQ IU IY Jb Jc Jd Je Jf Jg Jh Ji Jj Jk Jn Jq Jr Js Jt Jw Jx Jy Jz JG JJ
JK JQ JR JW JX JY JZ Kb Kc Kd Kf Kg Kh Kj Kl Ko Kq Kr Ks Ku Kv Kw Kx Ky Kz
KB KC KD KH KJ KK KN KO KU KV KW KX KY KZ Lg Lh Lj Lq Lr Lv Lw Lx Ly Lz LM
LQ LW LX Mc Md Mf Mh Mj Ml Mm Mp Mq Mr Mt Mv Mw Mx Mz MC MF MG MH MJ MR MV
MW MX MZ Nb Nc Nd Nf Ng Nh Nj Nl Nn Np Nq Nv Nw Nx Ny Nz NH NJ NQ NR NW NX
Oa Oe Oh Oi Oj Oo Oq Os Ox Oy Oz OH OJ OQ OY OZ Pb Pc Pf Pg Pj Pn Pp Pq Pw
Px Py Pz PF PG PH PM PN PQ PW PZ Qa Qb Qc Qd Qe Qf Qg Qh Qi Qj Qk Ql Qm Qn
Qo Qp Qq Qr Qs Qt Qv Qw Qx Qy Qz QA QB QC QD QF QG QH QI QJ QK QN QO QP QQ
QS QT QV QW QX QY QZ Rb Rc Rd Rf Rg Rj Rl Rn Rp Rq Rr Rs Rv Rw Rx Ry Rz RJ
RQ RV RX Sd Sf Sg Sj Sq Sv Sx Sz SD SG SJ SV SX Tb Td Tf Tg Tj Tl Tn Tq Tx
Tz TJ TK TQ TX TZ Ua Ub Uc Ud Ue Uf Ug Uh Ui Uj Uk Um Uo Uq Uu Uv Uw Ux Uy
Uz UH UJ UK UQ UU UV UW UX UY UZ Vb Vc Vd Vf Vg Vh Vj Vk Vl Vn Vq Vr Vt Vu
Vv Vw Vx Vy Vz VC VD VH VJ VK VN VP VQ VR VV VW VX VY VZ Wb Wc Wd Wf Wg Wj
Wl Wm Wn Wp Wq Wu Wv Ww Wx Wy Wz WC WD WE WF WG WJ WK WN WQ WT WU WV WW WX
WY WZ Xa Xb Xf Xg Xi Xj Xk Xq Xr Xu Xx Xy Xz XA XB XD XG XJ XK XL XN XQ XS
XU XV XW XZ Ya Yf Yj Yo Yq Yu Yx Yy Yz YB YC YF YG YH YJ YK YL YO YQ YR YU
YW YX YY YZ Zb Zc Zd Zf Zg Zh Zj Zk Zl Zm Zn Zp Zq Zr Zs Zt Zu Zv Zw Zx Zy
Zz ZB ZC ZD ZF ZG ZH ZI ZK ZL ZM ZP ZQ ZR ZS ZT ZU ZV ZW ZX ZZ

  --Rex

[Eugene Burmako]

No, mangling scheme is no longer exposed: https://github.com/scalamacros/kepler/blob/74d60036f59b4075fd18127e78c3a27592e40a71/src/reflect/scala/reflect/api/StandardNames.scala#L1

[Simon Ochsenreither]

No, mangling scheme is no longer exposed: https://github.com/scalamacros/kepler/blob/74d60036f59b4075fd18127e78c3a27592e40a71/src/reflect/scala/reflect/api/StandardNames.scala#L1

Great, thanks!

I already have a change which removes most of the mangling. The only failing tests seem to be related to expecting methods like $plus to exist (and one where a method name with a dot slips through, which I need to fix).
I'm thinking that runtime reflection mangling/demangling could even be handled by standard jdk classes (I have seen one for exactly this purpose in jdk7 tip, I just don't find it anymore ...). Just need to figure out since when they exist (JDK7+ wouldn't be that helpful, right?).

[Simon Ochsenreither]

Found it: http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/9b8c96f96a0f/src/share/classes/sun/invoke/util/BytecodeName.java

Too bad it is JDK7+ only :-/ It might be useful to use it in the compiler as a sanity check, though ...

[Simon Ochsenreither]

Is there a reason why ScalaCheck seems to be build against starr and not locker/quick?

I'm trying to get all tests to succeed, but ScalaCheck fails¹ because it doesn't seem to be built against the latest version but starr. What is the suggested workflow to rebuild ScalaCheck without introducing a commit where tests don't pass?

¹ test/scalacheck fails because the method names like ==> or |: don't get mangled and are not found anymore.

[Paul Phillips]

On Wed, Dec 26, 2012 at 4:44 PM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

Is there a reason why ScalaCheck seems to be build against starr and not locker/quick?

It probably relates to avoid building it all the time for no good reason. For sure when push comes to shove (i.e. if scalacheck isn't going to work) it should be built against quick.

[Simon Ochsenreither]

It probably relates to avoid building it all the time for no good reason. For sure when push comes to shove (i.e. if scalacheck isn't going to work) it should be built against quick.

Is there a recommended way to do that?

[Paul Phillips]

On Thu, Jan 3, 2013 at 2:06 PM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

Is there a recommended way to do that?

No, that was kind of a "pie in the sky" comment.