Shop OBEX P1 Docs P2 Docs Learn Events
Spin2 Operator Syntax - Page 14 — Parallax Forums

Spin2 Operator Syntax

11214161718

Comments

  • Dave Hein wrote:
    Isn't that more or less the same as "0 !< x !> 10" ? Or what if you did "0 <# x #> 10"? Oh, isn't that already what we have?
    Dave, did you try running that before you posted? I did:
    CON
    
      _clkmode      = xtal1 + pll16x
      _xinfreq      = 5_000_000
    
    OBJ
    
      sio   :       "Parallax Serial Terminal"
      
    PUB  start | i
    
      sio.start(9600)
      repeat i from -5 to 15
        sio.dec(0 <# i #> 10)
        sio.char(13)
    

    And I get all 10s in the output.

    -Phil
  • jmg wrote:
    I think // may have become the widespread comment to end of line?
    Maybe in C Land, but not here. // is the remainder operator in Spin1.

    -Phil
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2017-04-17 03:42
    jmg wrote:
    x := 0 FGE x FLE 10
    That order does not work with binary operators. That's why we need a trinary operator if x is to be the middle operand.

    -Phil
  • I have no problem with REM and MOD if both are implemented.

    -Phil
  • Cluso99Cluso99 Posts: 18,066
    edited 2017-04-17 04:33
    For the wordy operators why not prefix with # ?

    eg #MOD, #LIMS or #CLAMP (limits signed), etc.

    These could be alternatives (substitute whatever word is decided)
      #CLAMP (-10, x, 10)
      #CLAMP (-10, x,   ) // note the missing upper limit when there is only a lower limit
      #CLAMP (#  , x, 10) // upper limit only
    
  • jmgjmg Posts: 15,140
    Dave Hein wrote:
    .... Or what if you did "0 <# x #> 10"? Oh, isn't that already what we have?
    Dave, did you try running that before you posted? I did:
        sio.dec(0 <# i #> 10)
    
    And I get all 10s in the output.

    All of this confusion nicely illustrates exactly the problem with glyphs...

    The code by Jason posted back in page 8, was this
    Elev := 1000 #> Elev <# 2000 
    
  • jmgjmg Posts: 15,140
    jmg wrote:
    x := 0 FGE x FLE 10
    That order does not work with binary operators. That's why we need a trinary operator if x is to be the middle operand.
    If FGE means 'pick larger of' and FLE means 'pick smaller of', the above works fine, as also does x := (x FGE 0) FLE 10

  • I stand corrected. That does work. I know because I tried it:
    CON
    
      _clkmode      = xtal1 + pll16x
      _xinfreq      = 5_000_000
    
    OBJ
    
      sio   :       "Parallax Serial Terminal"
      
    PUB  start | i
    
      sio.start(9600)
      repeat i from -5 to 15
        sio.dec(0 #> i <# 10)
        sio.char(13)
    

    Did you?

    -Phil
  • Chip,
    I think for in Spin, just go with the operators as you discussed. I think it's fine. We can make whatever named functions we want out of them. I think it's actually best to have them be operators, so the names remain available for functions.

    The thing that needs fixing is the PASM instructions. MIN and MAX are just wrong for those.
  • jmgjmg Posts: 15,140
    Roy Eltham wrote: »
    The thing that needs fixing is the PASM instructions. MIN and MAX are just wrong for those.

    I think that's done - Chip did post this earlier
    cgracey wrote: »
    I like these, too, and they cover both signed and unsigned.

    MIN becomes FGE
    MAX becomes FLE
    MINS becomes FGES
    MAXS becomes FLES
    ...
    .. not sure if this still applies, looks fine to me ?
  • I have no problem with REM and MOD if both are implemented.

    -Phil
    Perhaps I have lost something but REM for me is remark, ie comment. This is also the first things that appear if I google for it.

    REM can be an alias for ' or // for end of line comments, nothing else.
  • Ariba wrote: »
    But is this more readable?
      x := max(0,min(x,10))
    
    The usual min/max functions are reversed if you want to limit in a range.
    They are okay to find the min or max, but not if you want to clip to min, max.
    It's the opposite meaning, that's why you never find one set of operators, or function names for both cases.

    Andy
    It looks more readable to me.

  • Heater.Heater. Posts: 21,230
    Chip,
    ...offends people because of their past experience, always seeing...
    You are so right.

    We all come at these things from different backgrounds and experiences. Even if they are not related to programming languages. What is blindingly obvious to one is cryptic gibberish to another.

    At the end of the day pretty much anyway to express anything works and is not logically any better or worse than any other. Provided you are not looking at it with preconceived ideas.

    That's why language wars are so much fun! White space delimiting vs braces, semicolons or not, this operator symbol or that. It's interesting to see where people come from in that respect. (I'm mean really "REM" for comments, what century is this? :) )

    This is unique though. A language war over a language that does not exist yet.

    It is said that "A camel is a horse designed by a committee." We trust you to come up with something that is not committee soup! Even if it does not please all committee members.

    (Hmm...I think that's a bit hard on Camels, considering the very different environment they have evolved to live in).





  • dMajodMajo Posts: 855
    edited 2017-04-17 13:55
    Heater. wrote: »
    That's why language wars are so much fun! White space delimiting vs braces, semicolons or not, this operator symbol or that. It's interesting to see where people come from in that respect. (I'm mean really "REM" for comments, what century is this? :)
    It's for sure the previous century since I am 45 .... and it stared from the ages of commodore 64 when I was 12 .... but beside being used in most if not in all the BASICs (including the modern ones) it is also used in batch scripts on windows platforms, also today.

    And this is the reason that when I see REM the first thing I think of is comment. If it's not then I need to google for it. But even today if you google for rem statement or rem command or rem instruction the first thing that comes out is comment.
  • Heater.Heater. Posts: 21,230
    Sadly I'm too old to be of the C64 generation. My first experience of programming was BASIC in 1973 or so, on a mainframe far away over a 300 baud serial connection.

    So, yeah, I know were REM comes from. Deep in the foggy past of computing history.

    As for REM in Windows BAT files. I have not done any of that since 1998. We have had Linux since then!

    Having said that, I'm not so sure I like "REM" being repurposed for "remainder". "REM" is just ugly whatever it's supposed to mean.

    But, that's just me.



  • I am also against REM for spin comments, my opinio is just that rem should not be used because of the above reasons.

    I like // for line comments and /* */ for block comments.
  • kwinnkwinn Posts: 8,697
    edited 2017-04-17 14:17
    jmg wrote: »
    Dave Hein wrote:
    .... Or what if you did "0 <# x #> 10"? Oh, isn't that already what we have?
    Dave, did you try running that before you posted? I did:
        sio.dec(0 <# i #> 10)
    
    And I get all 10s in the output.

    All of this confusion nicely illustrates exactly the problem with glyphs...

    The code by Jason posted back in page 8, was this
    
    

    What confusion? Read from left to right - Elev equals 1000 less than or equal to Elev, Elev less than or equal to 2000. The hardest part of that is memorizing the meaning of a few (what 6? 8? 10?) symbols. The only thing I can come up with that might be clearer would be Elev := 1000 #v Elev ^# 2000 or Elev := 999 v Elev v 2001, and they are only marginally better.

    Honestly, I don't know why we even bother with the "or equal" part. Greater than 999 and less than 2001 works just as well. Can anyone come up with a case where the "or equal" part is essential?
  • Heater.Heater. Posts: 21,230
    edited 2017-04-17 14:32
    kwinn,
    The hardest part of that is memorizing the meaning of a few (what 6? 8? 10?) symbols.
    Yep, that is 6? 8? 10? too many symbols to have to remember.

    Especially for those that use a dozen other languages that have their own cryptic symbols. Which can be very similar but have totally different meaning.

    How about we forget the ASCII restrictions? Spin supports Unicode to some extent. We could enter the modern era by adopting some of the millions of Unicode symbols. We could write, for example:

    x := 10 💩 x 😉 20

    It's just some symbols to remember, right?

    Twitter people could then be able to write software!

    (Err, no, I'm not serious).



  • kwinnkwinn Posts: 8,697
    So function names? How about for math? Get rid of those nasty symbols and use add, subt, mult, div, exp, and so on?
  • kwinn wrote: »
    So function names? How about for math? Get rid of those nasty symbols and use add, subt, mult, div, exp, and so on?
    No. Pretty much everyone knows those.
  • potatoheadpotatohead Posts: 10,253
    edited 2017-04-17 15:05
    At some point, one must invest.

    Way back, when I was first confronted with SPIN, it took an hour to understand a couple of the demo programs.

    Then, came one with an involved expression. Graphics_demo.spin has a couple used to generate color data, as an example.

    It took another hour to look them up, write what the expression did, plug raw values in to confirm.

    There were several more hours to come. But, it was possible to write programs fairly quickly at that point.

    Over the years, those expressions triggered many, how do color and tiles work questions. At one point, I wrote some code without them, creating methods for those tasks.

    Fewer questions have come since. When I post from desktop, It's in my signature.

    In PASM, similar things happened. The simple path got people on board more quickly, but also did limit what can happen.

    On P1 SPIN, those expressions are fast. And, one can pack a whole little program into them too. Very obtuse, but tight, fast, memory lean. On P1, this really matters!

    P2 SPIN will be faster as byte code, and faster still compiled.

    I'll bet the same dynamics come up though.

    P2 will bring more of everything, but the scope of tasks will increase too. Bigger buffers, faster signals, etc...

    At one point baggers crammed a level of WOLF3D into a P1, SPIN plus PASM. I remember having to pull out my reference card to parse that program.

    Nice that he was able to write that program. This is why we need to remember why some things in SPIN are the way they are. Chip tends to optimize toward this kind of thing being possible.

    Whatever we do with SPIN 2, I feel strongly about it performing like P1 SPIN does.

    Making compact, fast, powerful expressions is a part of that. When those get written, it's very likely most everyone will need to review before understanding that code.

    OK fine.

    Designing that away runs the cost and risk of also designing the performance, size and ease away too.

    Doing that is a mistake.

    On this byte code version of SPIN, doing things in some less than orthodox way, will make great sense in the context of the hardware, assembly language. Taken as a whole, it will make great sense. This should be primary.

    I see it much like I do the interrupt events. It's there, and when needed, welcome. Those will very significantly improve on the scope of possible tasks P2 can do well.

    A fast, compact, flexible, raw SPIN 2 will do the same.

    This is part of the sauce that people value. And when they experience it, they tend to be productive and have fun.

    Not all people, and it's fine. Absolutely nothing prevents others from bringing their vision to the table too.

    But, we have a lot of P1 users, who will expect these dynamics to be here on P2, enhanced, but not designed away.





  • Heater.Heater. Posts: 21,230
    edited 2017-04-17 15:16
    kwinn,
    So function names? How about for math? Get rid of those nasty symbols and use add, subt, mult, div, exp, and so on?
    Well....no.

    I like to think that anybody who ever made it to high school was taught some basic arithmetic. As such "+", "-", "×", "÷" and others have been ingrained in our culture for some thousand years or whatever. Even if you know nothing of programming they should be immediately recognizable.

    That is why languages like FORTRAN and BASIC etc were invented in the first place. To get away from the cryptic mnemonics of assembler that programmers used and provide a language that normal people could understand.

    Sadly the guys that specified ASCII saw fit to ignore "×", "÷" so we don't have it in the character set or on our keyboards. But "*" and "/" are close enough as to be obvious.

    Then there is the other big mistake that many languages make. Using "=" as an assignment. Which is not what it means in mathematics.

    Then we get into all the other weird, cryptic, operators that programming languages have introduced over time.

    Mind you, it seems high school kids today don't get taught how to do arithmetic or read and write much. That is why we need things like Blockly.


  • Heater.Heater. Posts: 21,230
    And another thing...

    Those ASCII designers decided to use "." for the decimal point. Which meant it could no longer be used as a multiply operator as anyone who has done high school maths might expect. So we are stuck with "*".

    We carry a lot of historical baggage here.
  • Heater - do you have one of these?
    808 x 234 - 70K
  • Heater.Heater. Posts: 21,230
    KeithE,

    No, what is that?

    Kind of reminds me of a Commodore Pet keyboard.

    No that I remember that very well now.
  • Heater.Heater. Posts: 21,230
    edited 2017-04-17 17:42
    Heck, does even Unicode have an actual decimal point? I can't find one.

    Edit: Perhaps this "·".

  • I doubt that the ASCII designers were the cause of * and /. (Extended ASCII actually includes × and ÷.) No, we have Herman Hollerith to "blame." His code was adopted by IBM for their punch cards, then along came Fortran, which used * and /. The rest is history.

    But IBM did not sit on a small character set for long, for then came APL. It had a huge set of cryptic operators (which operated right-to-left). An APL program looked almost runic. Keith's keyboard above shows some of the symbols used by APL. Here's a sample APL program:

    matrix.jpg

    Kinda makes interpreting Spin code seem like reading an English primer by comparison, doesn't it?

    -Phil
  • Heater.Heater. Posts: 21,230
    Can't really blame the ASCII guys I guess. They were stuck for space and did a pretty good job.

    Ah, APL. Let's not go there.
    Kinda makes interpreting Spin code seem like reading an English primer by comparison, doesn't it?
    Yes.

    Or at least I used to think so before I saw some of the suggestions cropping up here.

    Let's see what we end up with.
  • My mom had to take a programming class as part of her MBA program, and got stuck learning APL. As far as I know she never used it after passing that class.
  • kwinnkwinn Posts: 8,697
    David Betz wrote: »
    kwinn wrote: »
    So function names? How about for math? Get rid of those nasty symbols and use add, subt, mult, div, exp, and so on?
    No. Pretty much everyone knows those.

    That was more of a tongue in cheek than a serious suggestion.


    Heater. wrote: »
    kwinn,

    Well....no.

    I like to think that anybody who ever made it to high school was taught some basic arithmetic. As such "+", "-", "×", "÷" and others have been ingrained in our culture for some thousand years or whatever. Even if you know nothing of programming they should be immediately recognizable.

    That "ingraining" had a starting point, so is it not reasonable to expect that someone who wants to program computers would have to learn to use the symbols and functions needed.
Sign In or Register to comment.