Return to “Scripting & Modding”

Post

Re: LTSL - The LT script language

#50
I started with MS-DOS' 'edit'. Then I moved to notepad. Then Textpad, and finally notepad++ if I'm not using an IDE.

In linux, I preferred Nano just because I prefer basic text editors. Yes, I'm archaic like that.
Image
Early Spring - 1055: Well, I made it to Boatmurdered, and my initial impressions can be set forth in three words: What. The. F*ck.
Post

Re: LTSL - The LT script language

#52
I wrote my very first line of code using copy con on a 286 without hard drive.
I was 10 at the time so didn't have any real idea what I was doing. I was just trying something out that I read in a library book.

An editor would have been wasted on me, since I couldn't understand English yet.
Beware of he who would deny you access to information, for in his heart he dreams himself your master.
Post

Re: LTSL - The LT script language

#53
Maybe we need a separate thread for an extended editor-of-choice discussion. Good stuff!

Back to Josh's latest tidbits about LTSL, I hope someone will pick up on his comments today about how nice it would be if types can be easily defined and extended. Bonus points for explaining clearly how that makes "metaprogramming" easier. ;)

For now, I'd just like to ask a dumb question. I see again in Josh's LTSL example of a for-loop that the third parameter -- the part that changes the loop value if the loop test evaluates to "true" -- is given as "(++ i)".

As an old C programmer, my first interpretation of this is that it's pre-incrementing the value of i... but of course in LTSL that's not what this is doing. It's actually (I think!) passing the value of i to the ++() function (or overloaded increment() function), which adds 1 and returns the result.

(Incidentally, I think that answers my question of whether LTSL is call-by-reference. ;))

So does that mean ++() is always/only the post-increment form? As presumably --() is only post-decrement?

Does that mean that LTSL doesn't have a concise way of expressing pre-increment and pre-decrement, meaning that the value is updated before anything else in the same statement?

I'm not vexed either way. I don't use pre-inc/dec myself as I think it's so subtle in its effect on processing logic that it's a good way to get yourself in trouble semantically. But certainly there are people who do use it. So it's interesting that LTSL's for-loop might not have an equivalent of C's way to alter a for-loop value prior to testing it, even though that's almost what "(++ i)" looks like to a C programmer.

Not a criticism, just curious.
Post

Re: LTSL - The LT script language

#54
Flatfingers wrote: Back to Josh's latest tidbits about LTSL, I hope someone will pick up on his comments today about how nice it would be if types can be easily defined and extended. Bonus points for explaining clearly how that makes "metaprogramming" easier. ;)
It reminds me of prototype-based inheritance, as seen in Javascript. I don't know how much the systems will have in common, but you may look at http://stackoverflow.com/questions/3462 ... -prototype for people discussing the benefits.

As for the metaprogramming part, I guess it refers to the ability to create new types without handwriting them beforehand. Both field names and their default values can be set (and reset) at any time, even in run-time.

EDIT: after reading the devlog discussion, it seems it won't be js-like prototypes. Josh wants compiling for efficiency, while prototypes are usually (only?) found in interpreted languages. I'm not awfully knowledgeable about the inner workings of languages, though, so take it with a spoonful of salt :D

The benefits might still be similar to the above, as they are related to classes being editable in runtime, which still seems to be the case.
Flatfingers wrote: As an old C programmer, my first interpretation of this is that it's pre-incrementing the value of i... but of course in LTSL that's not what this is doing. It's actually (I think!) passing the value of i to the ++() function (or overloaded increment() function), which adds 1 and returns the result.
In functional programming, this is the case yes. (++ i) (also often appears as (succ i)) is equivalent to (+ i 1) and i+1. However, this doesn't set the i-symbol to the new value, as seems to be the case for LTSL by looking at the for loop. Could be the for loop is a macro which does (set i <exp>), where <exp> is the expression where (++ i) currently is, but I find that unlikely.
Post

Re: LTSL - The LT script language

#55
I guess I'm a bit late following this. I didn't see this forum section until now. xD
I have several ideas and thoughts on LTSL. I've been poking around in Scala for a few months now, so a large portion of this post may have has been influenced by that experience. :monkey:

I hope everything will treated as data. "Special keywords" could be implemented as "native" functions. That would make LTSL a lot nicer to work with. The fact that type descriptors are treated as data is already really nice. :thumbup:

Will type descriptors be "created" dynamically or at compile-time?

Any symbol like

Code: Select all

?,+-`!^
should be allowed in function and varaible names. That allows for "operator overloading" and cool DSLs. Taking an example from Scala:

Code: Select all

val someNumber = 5 * 5 // This is equivalent to 5.*(5)
object $ { // Singleton object
  def apply(str: String) = println(str)
}
// jQuery style!
$("test") // Calls $.apply("test"), which prints out "test"
I think you should handle indented code as a function. Wait, a function is essentially a value. Please ignore this snippet.
As an example, this is what a function in Scala may look like:

Code: Select all

def doSomething(block: Int => Int) = {
  block(5)
}

doSomething { myNumber => 
  val example = myNumber + 5
  example * 5
}
The "doSomething" block is actually a function that takes an integer and returns an integer.

Since type descriptors are just data, inheritance could be implemented by having subtypes instantiate supertypes:

Code: Select all

Var SuperType TypeDescriptor_New
// Add fields, etc.
Var SubType (New SuperType)
How will multiple inheritance be handled?
Edit: It could be handled like how Scala cleverly handles it.

Edit 2: My idea, taking Josh's asteroid example to the extreme:

Code: Select all

// For simplicity/less verbosity, I will refer to calling a function as Function(Parameter, Parameter2, ...)
// Extra parentheses for clarity
    Script System_Simple // Script("System_Simple", Function)
      Param int asteroids  // Param(Type(int), "asteroids") -- int could already be defined as a TypeDescriptor, though
      Param RNG rng        // Param(Type(RNG), "rng") -- same here

      Var kSystemScale 1000        // Var("kSystemScale", 1000)
      Var system System_Create  // Var("system", System_Create)

      For i 0 (< i asteroids) (++ i) // For("i", 0, <("i", asteroids), ++("i"), Function)
        Var asteroid (Asteroid_Create (RNG_Int rng)) // Var(asteroid, Asteroid_Create(RNG_Int, rng))
             // Object_SetPos(*(kSystemScale(RNG_Direction(rng), RNG_Exponential(rng)))
        Object_SetPos (* kSystemScale (RNG_Direction rng) (RNG_Exponential rng)) 
        Object_AddInterior system asteroid // Object_AddInterior(system, asteroid)

      system // last value is always the "return" value
Of course, this is all speculation. Unless Josh confirms it himself. :D
I should post more and lurk less...
Post

Re: LTSL - The LT script language

#56
After a lot more hard work over the past few days, LTSL sounds like it's approaching completion.

The code example in today's devlog was really helpful for getting a better idea of what LTSL will look like in practice. Regardless of any questions I might have about its structure, I really appreciate being shown this work in progress. Any questions I have are the product of my lack of understanding.

Did I mention I have questions? ;)

LTSL's switch statement/function, to begin with, is noteworthy in that the value to be tested is in each case, rather than once at the top of the switch. I already like this much better than the switch() in C/Java, which has always felt too limited to me.

About that switch in LTSL, then:

1. Does processing start with the first case and then exit the switch after processing the statements in the first case that evaluates to true? Otherwise, suppose that i is equal to 7: all of the three cases in the example would be processed, wouldn't they?

2. Is the LTSL "case true" test statement equivalent to the C/Java "default:" test statement in a switch?

3. Is there an implied break after exiting the last indentation of a case? If so, is fall-through not supported?

Also:

4. var confuses me. In some cases it appears to be a function because it seems to take at least one typed parameter, rather than just a type name. But that doesn't make sense, so I'm guessing that the supplied type of what looks like the parameter must actually be the type of the variable being declared... but then what is that parameter? Is it an initializer value of some kind?

5. Er... how are comments denoted?

Finally, I took the liberty of converting Josh's sample code from today into something that looks more like C/Java while retaining what I guess is the same functionality.

Here's Josh's example, following by my suggested conversion:

Code: Select all

function (Test2 (Int count))
  function (MyFn (Int n))
    function (MySubFn (Int n)) (* n n)
    function (MySubFn2 (Int n)) (+ (* n 2) 3)
    MySubFn2 (MySubFn n)

  function (List_Dupe (List l))
    var sz (Size l)
    for i 0 (< i sz) (++ i)
      Append l (List_Get l i)
    l

  var list (List (Int 0))
  var rng (RNG_MTG count)
  Append list 1337

  for i 0 (< i count) (++ i)
    switch
      case (> i 6)
        Append list (Int (+ 1.0 1.999999))
      case (> i 3)
        Append list 0
      case true
        Append list (RNG_Int rng 0 10000)

  for i 0 (< i (Size list)) (++ i)
    @ (+ "Element " i " = " (Int (Get list i)))

  list

Code: Select all

function Test2(Int count)
{
  function MyFn(Int n)
  {
    function MySubFn(Int n)
    {
      return(n * n);
    }

    function MySubFn2(Int n)
    {
      return((n * 2) + 3);
    }

    return(MySubFn2(MySubFn(n)));
  }

  function List_Dupe(List l)
  {
    Int sz = l.Size();
    for (i = 0; i < sz; i++)
      l.Append(l.List_Get(i));
    return(l);
  }

  List list = new List(0);
  RNG_MTG rng = new RNG_MTG(count);

  list.Append(1337);

  for (i = 0; i < count; i++)
  {
    switch
    {
      case (i > 6):
        list.Append(Int (1.0 + 1.999999));
      case (i > 3):
        list.Append(0);
      case true:
        list.Append(RNG_Int (rng(0,10000)));
    }
  }

  for (i = 0; i < list.Size(); i++)
    print("Element " + i + " = " + Int (list.Get(i)));

  return(list);
}
I won't editorialize on this. I just thought it might be interesting to have a clear comparison. People can decide for themselves what they think.

Online Now

Users browsing this forum: No registered users and 1 guest

cron