Advertisement
sci4me

Lua Pointer/Reference Sillyness BS

Feb 27th, 2018 (edited)
56
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 3.19 KB | None | 0 0
  1. Thoughts on pointers/references in Lua++:
  2.  
  3. I spent a lot of time thinking about this last night and so far, the conclusion I've reached is that it simply does not make sense to have pointers or references in this language. At least not in the traditional sense.
  4.  
  5. I can imagine *at least* one way to implement a pointer in this language: as a function. It's not ideal but bear with me...
  6.  
  7. Say I want to write something like this:
  8.  
  9. double :: (int& a) {
  10. *a *= 2;
  11. }
  12.  
  13. b : int = 42;
  14. double(&b);
  15.  
  16. That could translate into this (potentially):
  17.  
  18. function double(a)
  19. a(a() * 2)
  20. end
  21.  
  22. local b = 42
  23. double(function(x)
  24. if x then b = x end
  25. return b
  26. end)
  27.  
  28. It's a bit .. shitty, having to use a closure to implement a pointer like this but it seems like the simplest way to do it to me, if not the "only" way. I mean the alternative would be, I guess, storing everything in invisible arrays that I can pass around... But then *all* data would take a performance hit. The advantage of this approach is that its performance hit is actually relatively minimal. In the case of a struct/array reference/pointer, a closure wouldn't even be needed since they're already reference types, whereas, if it were being used as a value type, extra code would be needed to implement the copying.
  29.  
  30. This is all fine and dandy but then, what about pointer arithmetic? The only case where it would seem to even make sense is in the case of a pointer to an array element. In all other cases the behavior would likely just be undefined? I mean.. eh..
  31. Even if it makes sense though, how? It would require a different implementation...
  32.  
  33. One theoretical implemention may be to use a function that takes in an expression at runtime and generates the pointer closure from that... But like... that's kind of insane and would be pretty damn slow... idk.
  34. What I meant by that:
  35.  
  36. a : []int = [ 0, 2, 6, 4, 9, 5 ];
  37. b := &a[0];
  38. c := &a[5];
  39.  
  40. for b != c {
  41. *b *= 4;
  42. b++;
  43. }
  44.  
  45. And in Lua:
  46.  
  47. local a = { 0, 2, 6, 4, 9, 5 }
  48. local b = function(x)
  49. if x then a[0] = x end
  50. return a[0]
  51. end
  52. local c = function(x)
  53. if x then a[5] = x end
  54. return a[5]
  55. end
  56.  
  57. (*at this point, I realize that a pointer would actually necessarily be a table with overridden __eq and __call so that comparing pointers would be possible; maybe a table/metatable-based approach would simplify things and be better, but it would also be a further performance hit*)
  58.  
  59. function __ptr_expr_*unique-id*(*something*) -- obviously *unique-id* is some expr identifier from the copiler
  60. -- so... uh... shit. maybe i need table-based pointers to be able to do this at all? er... hmmh... yeah.............. (dotdotdot)
  61. end
  62.  
  63. while b ~= c do -- pretend that comparison will work; see just above
  64. b(b() * 4)
  65. b = __ptr_expr_*unique-id*(*something?*)
  66. end
  67.  
  68. Yeah idk where exactly I was going with that... meh. Seems pointless to try since I really don't think pointer arithmetic makes sense in this language... but I'll be very eager to hear your thoughts...
  69.  
  70. And if we don't do pointer arithmetic, why do pointers? Seems like the only use-cases would be modifying function parameters and having references to array elements and struct members...
  71.  
  72. But like.. eh.. is that even that useful? Idk
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement