Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #20459 > unrolled thread
| Started by | Tim Wescott <seemywebsite@myfooter.really> |
|---|---|
| First post | 2015-03-13 16:27 -0500 |
| Last post | 2015-03-19 12:02 +0100 |
| Articles | 20 on this page of 80 — 21 participants |
Back to article view | Back to comp.arch.embedded
Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Tim Wescott <seemywebsite@myfooter.really> - 2015-03-13 16:27 -0500
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-13 15:03 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Tim Wescott <seemywebsite@myfooter.really> - 2015-03-13 19:04 -0500
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? rickman <gnuarm@gmail.com> - 2015-03-18 02:34 -0400
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2015-03-18 12:37 +0000
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Tim Wescott <seemywebsite@myfooter.really> - 2015-03-13 19:06 -0500
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-13 18:14 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Tom Gardner <spamjunk@blueyonder.co.uk> - 2015-03-13 22:30 +0000
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? David Brown <david.brown@hesbynett.no> - 2015-03-14 00:48 +0100
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Paul Rubin <no.email@nospam.invalid> - 2015-03-13 19:45 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? David Brown <david.brown@hesbynett.no> - 2015-03-15 23:01 +0100
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? mroberds@att.net - 2015-03-14 00:28 +0000
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-13 18:45 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Clifford Heath <no.spam@please.net> - 2015-03-14 13:14 +1100
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-13 20:35 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? George Neuner <gneuner2@comcast.net> - 2015-03-14 23:59 -0400
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-14 22:30 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? George Neuner <gneuner2@comcast.net> - 2015-03-15 21:44 -0400
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-15 20:09 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? George Neuner <gneuner2@comcast.net> - 2015-03-14 23:59 -0400
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-16 15:42 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? George Neuner <gneuner2@comcast.net> - 2015-03-17 04:25 -0400
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-17 10:39 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? George Neuner <gneuner2@comcast.net> - 2015-03-17 17:06 -0400
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-17 19:36 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? George Neuner <gneuner2@comcast.net> - 2015-03-18 01:50 -0400
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-17 23:32 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-18 05:30 -0500
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-18 10:32 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-18 16:11 -0500
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-18 18:26 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? George Neuner <gneuner2@comcast.net> - 2015-03-19 02:09 -0400
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-19 12:04 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? George Neuner <gneuner2@comcast.net> - 2015-03-19 17:52 -0400
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-19 15:44 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? George Neuner <gneuner2@comcast.net> - 2015-03-20 02:38 -0400
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? David Brown <david.brown@hesbynett.no> - 2015-03-20 10:05 +0100
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-20 02:51 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? David Brown <david.brown@hesbynett.no> - 2015-03-20 11:49 +0100
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-20 05:12 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? David Brown <david.brown@hesbynett.no> - 2015-03-20 14:55 +0100
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-20 15:07 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? George Neuner <gneuner2@comcast.net> - 2015-03-20 14:11 -0400
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-20 15:20 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? George Neuner <gneuner2@comcast.net> - 2015-03-22 09:28 -0400
OT: EoL Don Y <this@is.not.me.com> - 2015-03-22 12:19 -0700
Re: OT: EoL Reinhardt Behm <rbehm@hushmail.com> - 2015-03-23 07:30 +0800
Re: OT: EoL Don Y <this@is.not.me.com> - 2015-03-22 17:19 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-20 02:12 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Mel Wilson <mwilson@the-wire.com> - 2015-03-20 13:24 +0000
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-20 10:20 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? George Neuner <gneuner2@comcast.net> - 2015-03-22 08:12 -0400
OT: senses Don Y <this@is.not.me.com> - 2015-03-22 13:53 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Wouter van Ooijen <wouter@voti.nl> - 2015-03-15 10:11 +0100
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? mroberds@att.net - 2015-03-14 07:50 +0000
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Mel Wilson <mwilson@the-wire.com> - 2015-03-14 12:24 +0000
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Don Y <this@is.not.me.com> - 2015-03-14 11:46 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? George Neuner <gneuner2@comcast.net> - 2015-03-14 23:58 -0400
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Clifford Heath <no.spam@please.net> - 2015-03-14 12:59 +1100
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Paul Rubin <no.email@nospam.invalid> - 2015-03-13 20:16 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Tim Wescott <tim@seemywebsite.com> - 2015-03-13 23:20 -0500
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Paul Rubin <no.email@nospam.invalid> - 2015-03-13 22:29 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Paul Rubin <no.email@nospam.invalid> - 2015-03-13 22:46 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Stefan Reuther <stefan.news@arcor.de> - 2015-03-14 11:02 +0100
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Anders.Montonen@kapsi.spam.stop.fi.invalid - 2015-03-16 11:37 +0000
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Paul Rubin <no.email@nospam.invalid> - 2015-03-16 13:53 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-14 03:16 -0500
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2015-03-14 10:27 +0200
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2015-03-14 08:43 +0000
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2015-03-14 13:55 +0200
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2015-03-14 12:14 +0000
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? stephen@mpeforth.com (Stephen Pelc) - 2015-03-14 18:04 +0000
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2015-03-14 23:14 +0200
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Allan Herriman <allanherriman@hotmail.com> - 2015-03-14 10:08 +0000
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? George Neuner <gneuner2@comcast.net> - 2015-03-15 00:55 -0400
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Paul Rubin <no.email@nospam.invalid> - 2015-03-14 22:20 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? George Neuner <gneuner2@comcast.net> - 2015-03-15 20:35 -0400
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Paul Rubin <no.email@nospam.invalid> - 2015-03-15 18:47 -0700
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? stephen@mpeforth.com (Stephen Pelc) - 2015-03-18 10:03 +0000
Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-03-19 12:02 +0100
Page 1 of 4 [1] 2 3 4 Next page →
| From | Tim Wescott <seemywebsite@myfooter.really> |
|---|---|
| Date | 2015-03-13 16:27 -0500 |
| Subject | Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? |
| Message-ID | <kdCdnY1enJGty57InZ2dnUU7-VOdnZ2d@giganews.com> |
The title says most of it. I'm working on a project for which the customer wants a lot of flexibility to customize a product. The existing "macro language" is ancient (ca 1985), cryptic (it looks like machine language), limited, clunky, etc. The customer is willing to change. I'm planning on having a chunk of serial flash (or an SD card) with a file system on it (maybe FAT, maybe something home-rolled and primitive). Scripts will be stored as text files, and read in as appropriate. Rather than just use some clunky cryptic and limited language that's unique to the problem and to me (and charging my customer up the wazoo for it), I'd like to use something that's open-source and available. Something that uses modest resources is to be preferred -- my understanding is that I can expect Lua to use about 100k of flash, which is a bit much for me but bearable. I don't know how Tcl compares -- I just know that it's an alternative. So -- anyone have any direct experience with either of these, or with something else? We briefly considered Java, but it just looks entirely too big -- it would basically drive us to use Linux or some other "real" OS (even the little linuxes are too big for my tastes) -- I'd really rather just have a scripting engine that gets called whenever a script needs to run, and otherwise doesn't need much hand-holding from the application code. I'm looking for opinions, so fire away! -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
[toc] | [next] | [standalone]
| From | Don Y <this@is.not.me.com> |
|---|---|
| Date | 2015-03-13 15:03 -0700 |
| Message-ID | <mdvmqd$hae$1@speranza.aioe.org> |
| In reply to | #20459 |
Hi Tim, On 3/13/2015 2:27 PM, Tim Wescott wrote: > The title says most of it. > > I'm working on a project for which the customer wants a lot of flexibility > to customize a product. The existing "macro language" is ancient (ca > 1985), cryptic (it looks like machine language), limited, clunky, etc. > The customer is willing to change. > > I'm planning on having a chunk of serial flash (or an SD card) with a file > system on it (maybe FAT, maybe something home-rolled and primitive). > Scripts will be stored as text files, and read in as appropriate. > > Rather than just use some clunky cryptic and limited language that's > unique to the problem and to me (and charging my customer up the wazoo for > it), I'd like to use something that's open-source and available. > Something that uses modest resources is to be preferred -- my > understanding is that I can expect Lua to use about 100k of flash, which > is a bit much for me but bearable. I don't know how Tcl compares -- I > just know that it's an alternative. > > So -- anyone have any direct experience with either of these, or with > something else? We briefly considered Java, but it just looks entirely > too big -- it would basically drive us to use Linux or some other "real" > OS (even the little linuxes are too big for my tastes) -- I'd really > rather just have a scripting engine that gets called whenever a script > needs to run, and otherwise doesn't need much hand-holding from the > application code. > > I'm looking for opinions, so fire away! I think Blue is better than Red. Bagels beat donuts hands down! (unless you're *not* in NYC; then damn near ANYTHING beats a bagel!) Chicago Pizza beats New York Pizza. 42 Connery over all others (Moore, Brosnan, Lazenby, Dalton, Craig) Anything with butter. As to *your* question... What sorts of things does the customer expect to *do* with those scripts? And, (besides space) what other constraints are you needing to place on those actions? E.g., any timeliness constraints? Performance? Numerical precision? etc. Who is the intended user: *just* the client? Or, will these things be exposed to users? What sorts of things do the scripts interact with (displays, etc.)? E.g., do you need to be able to manipulate a GUI without constraint? Or, are you just serving up text and/or canned dialogs? What sort of user input device (keyboard, keypad, etc.)? Other I/O's? I opted for a (bastardized) Limbo as my scripting language. But, I use it to generate "real" applications and not just automate some preexisting actions. However, it won't fit your memory requirements. Can you tolerate something as "crude" as a bastardized BASIC? I.e., add "product specific" hooks to it to address some of the special needs (displays, etc.) at a "native" level. A BASIC interpreter/compiler can be really small. The same can be said of C interpreters, mini-compilers (JIT). But, you'd be targeting a different class of "developer" (user). --don
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <seemywebsite@myfooter.really> |
|---|---|
| Date | 2015-03-13 19:04 -0500 |
| Message-ID | <kdCdnY9enJGH5p7InZ2dnUU7-VOdnZ2d@giganews.com> |
| In reply to | #20460 |
On Fri, 13 Mar 2015 15:03:09 -0700, Don Y wrote: > Hi Tim, > > On 3/13/2015 2:27 PM, Tim Wescott wrote: >> The title says most of it. >> >> I'm working on a project for which the customer wants a lot of >> flexibility to customize a product. The existing "macro language" is >> ancient (ca 1985), cryptic (it looks like machine language), limited, >> clunky, etc. The customer is willing to change. >> >> I'm planning on having a chunk of serial flash (or an SD card) with a >> file system on it (maybe FAT, maybe something home-rolled and >> primitive). Scripts will be stored as text files, and read in as >> appropriate. >> >> Rather than just use some clunky cryptic and limited language that's >> unique to the problem and to me (and charging my customer up the wazoo >> for it), I'd like to use something that's open-source and available. >> Something that uses modest resources is to be preferred -- my >> understanding is that I can expect Lua to use about 100k of flash, >> which is a bit much for me but bearable. I don't know how Tcl compares >> -- I just know that it's an alternative. >> >> So -- anyone have any direct experience with either of these, or with >> something else? We briefly considered Java, but it just looks entirely >> too big -- it would basically drive us to use Linux or some other >> "real" OS (even the little linuxes are too big for my tastes) -- I'd >> really rather just have a scripting engine that gets called whenever a >> script needs to run, and otherwise doesn't need much hand-holding from >> the application code. >> >> I'm looking for opinions, so fire away! > << smart-assery snipped >> > > As to *your* question... > > What sorts of things does the customer expect to *do* with those > scripts? > And, (besides space) what other constraints are you needing to place on > those actions? E.g., any timeliness constraints? Performance? > Numerical precision? etc. > > Who is the intended user: *just* the client? Or, will these things be > exposed to users? > > What sorts of things do the scripts interact with (displays, etc.)? > E.g., do you need to be able to manipulate a GUI without constraint? > Or, are you just serving up text and/or canned dialogs? > > What sort of user input device (keyboard, keypad, etc.)? Other I/O's? > > I opted for a (bastardized) Limbo as my scripting language. But, I use > it to generate "real" applications and not just automate some > preexisting actions. However, it won't fit your memory requirements. > > Can you tolerate something as "crude" as a bastardized BASIC? I.e., > add "product specific" hooks to it to address some of the special needs > (displays, etc.) at a "native" level. A BASIC interpreter/compiler can > be really small. > > The same can be said of C interpreters, mini-compilers (JIT). But, > you'd be targeting a different class of "developer" (user). The product will have a character display, and it'll store text files for later retrieval. It has a measurement thingie (I don't want to get too specific -- but it makes measurements) that'll cough up a number when it's actuated, and it has a sea of (well, around 100) buttons that the user can press. My intention at the moment is to make the box this big dumb thing with some system code that knows to call a function for each measurement and button press (i.e., when the user presses button 1, the function named "button_1" will get called if it exists). Then I'll encode the actual functionality as a bunch of functions in the language-o-choice. The nice thing about this is that if a user comes up with some desired customization (which we expect, as we're replacing an existing product for which this was common), we can either tell them to start coding and have fun, or we can charge them $$ to code the thing up to their specifications. The real driver for wanting to do this as a scripting language is to make it easy for the user to customize. I'm imagining that some users won't want to touch the customization with a 10 foot pole, some will be happy to customize a button or two, some will get their feet wet and then call us, and some will go whole hog with the thing, and do entire systems without us even knowing it's going on. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-03-18 02:34 -0400 |
| Message-ID | <meb67a$c8$1@dont-email.me> |
| In reply to | #20463 |
On 3/13/2015 8:04 PM, Tim Wescott wrote: > On Fri, 13 Mar 2015 15:03:09 -0700, Don Y wrote: > >> Hi Tim, >> >> On 3/13/2015 2:27 PM, Tim Wescott wrote: >>> The title says most of it. >>> >>> I'm working on a project for which the customer wants a lot of >>> flexibility to customize a product. The existing "macro language" is >>> ancient (ca 1985), cryptic (it looks like machine language), limited, >>> clunky, etc. The customer is willing to change. >>> >>> I'm planning on having a chunk of serial flash (or an SD card) with a >>> file system on it (maybe FAT, maybe something home-rolled and >>> primitive). Scripts will be stored as text files, and read in as >>> appropriate. >>> >>> Rather than just use some clunky cryptic and limited language that's >>> unique to the problem and to me (and charging my customer up the wazoo >>> for it), I'd like to use something that's open-source and available. >>> Something that uses modest resources is to be preferred -- my >>> understanding is that I can expect Lua to use about 100k of flash, >>> which is a bit much for me but bearable. I don't know how Tcl compares >>> -- I just know that it's an alternative. >>> >>> So -- anyone have any direct experience with either of these, or with >>> something else? We briefly considered Java, but it just looks entirely >>> too big -- it would basically drive us to use Linux or some other >>> "real" OS (even the little linuxes are too big for my tastes) -- I'd >>> really rather just have a scripting engine that gets called whenever a >>> script needs to run, and otherwise doesn't need much hand-holding from >>> the application code. >>> >>> I'm looking for opinions, so fire away! >> > << smart-assery snipped >> >> >> As to *your* question... >> >> What sorts of things does the customer expect to *do* with those >> scripts? >> And, (besides space) what other constraints are you needing to place on >> those actions? E.g., any timeliness constraints? Performance? >> Numerical precision? etc. >> >> Who is the intended user: *just* the client? Or, will these things be >> exposed to users? >> >> What sorts of things do the scripts interact with (displays, etc.)? >> E.g., do you need to be able to manipulate a GUI without constraint? >> Or, are you just serving up text and/or canned dialogs? >> >> What sort of user input device (keyboard, keypad, etc.)? Other I/O's? >> >> I opted for a (bastardized) Limbo as my scripting language. But, I use >> it to generate "real" applications and not just automate some >> preexisting actions. However, it won't fit your memory requirements. >> >> Can you tolerate something as "crude" as a bastardized BASIC? I.e., >> add "product specific" hooks to it to address some of the special needs >> (displays, etc.) at a "native" level. A BASIC interpreter/compiler can >> be really small. >> >> The same can be said of C interpreters, mini-compilers (JIT). But, >> you'd be targeting a different class of "developer" (user). > > The product will have a character display, and it'll store text files for > later retrieval. It has a measurement thingie (I don't want to get too > specific -- but it makes measurements) that'll cough up a number when it's > actuated, and it has a sea of (well, around 100) buttons that the user can > press. > > My intention at the moment is to make the box this big dumb thing with > some system code that knows to call a function for each measurement and > button press (i.e., when the user presses button 1, the function named > "button_1" will get called if it exists). Then I'll encode the actual > functionality as a bunch of functions in the language-o-choice. > > The nice thing about this is that if a user comes up with some desired > customization (which we expect, as we're replacing an existing product for > which this was common), we can either tell them to start coding and have > fun, or we can charge them $$ to code the thing up to their specifications. > > The real driver for wanting to do this as a scripting language is to make > it easy for the user to customize. I'm imagining that some users won't > want to touch the customization with a 10 foot pole, some will be happy to > customize a button or two, some will get their feet wet and then call us, > and some will go whole hog with the thing, and do entire systems without > us even knowing it's going on. I think what you are describing is Forth. There are two commercial vendors, MPE and Forth Inc. I know the MPE license allows you to embed the "interpreter" into your product for the customer to use. There are also open source Forths around, but with varying levels of embeddability and support. One is Mecrisp which is available for a few of the many ARM processors around and the TMS430 I believe. There are many others. Forth can be idiot simple to use. The assumption is it has a serial terminal for I/O or something much like it. I/O can be redirected from/to files or anything else by using deferred words. It can run on the bare metal or under an OS. You can give as much power to your customer as you think they can handle or as little as you think is wise. I've cross posted this to the forth group to get input from some of the regulars there. Oh, about the "file system". If you are happy with no file system at all, Forth can treat your storage as "blocks" of 1 KB and no real files at all. You can't get much simpler than that. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul E Bennett <Paul_E.Bennett@topmail.co.uk> |
|---|---|
| Date | 2015-03-18 12:37 +0000 |
| Message-ID | <cmt9rvF4692U2@mid.individual.net> |
| In reply to | #20515 |
rickman wrote: [%X] >> The real driver for wanting to do this as a scripting language is to make >> it easy for the user to customize. I'm imagining that some users won't >> want to touch the customization with a 10 foot pole, some will be happy >> to customize a button or two, some will get their feet wet and then call >> us, and some will go whole hog with the thing, and do entire systems >> without us even knowing it's going on. > > I think what you are describing is Forth. There are two commercial > vendors, MPE and Forth Inc. I know the MPE license allows you to embed > the "interpreter" into your product for the customer to use. There are > also open source Forths around, but with varying levels of embeddability > and support. One is Mecrisp which is available for a few of the many > ARM processors around and the TMS430 I believe. There are many others. > > Forth can be idiot simple to use. The assumption is it has a serial > terminal for I/O or something much like it. I/O can be redirected > from/to files or anything else by using deferred words. It can run on > the bare metal or under an OS. You can give as much power to your > customer as you think they can handle or as little as you think is wise. > > I've cross posted this to the forth group to get input from some of the > regulars there. > > Oh, about the "file system". If you are happy with no file system at > all, Forth can treat your storage as "blocks" of 1 KB and no real files > at all. You can't get much simpler than that. Sometimes don't you wish Usenet had a "Like" button? MPE's VxfForth is probably best for most of the platforms you are likely to be dealing with these days. I do recall suggesting Forth earlier in this thread. You really can design the script language you want and make it seem quite natural to the user. -- ******************************************************************** Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk> Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk> Mob: +44 (0)7811-639972 Tel: +44 (0)1392-426688 Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <seemywebsite@myfooter.really> |
|---|---|
| Date | 2015-03-13 19:06 -0500 |
| Message-ID | <kdCdnY5enJEG5p7InZ2dnUU7-VOdnZ2d@giganews.com> |
| In reply to | #20460 |
On Fri, 13 Mar 2015 15:03:09 -0700, Don Y wrote: > Hi Tim, > > On 3/13/2015 2:27 PM, Tim Wescott wrote: >> The title says most of it. >> >> I'm working on a project for which the customer wants a lot of >> flexibility to customize a product. The existing "macro language" is >> ancient (ca 1985), cryptic (it looks like machine language), limited, >> clunky, etc. The customer is willing to change. >> >> I'm planning on having a chunk of serial flash (or an SD card) with a >> file system on it (maybe FAT, maybe something home-rolled and >> primitive). Scripts will be stored as text files, and read in as >> appropriate. >> >> Rather than just use some clunky cryptic and limited language that's >> unique to the problem and to me (and charging my customer up the wazoo >> for it), I'd like to use something that's open-source and available. >> Something that uses modest resources is to be preferred -- my >> understanding is that I can expect Lua to use about 100k of flash, >> which is a bit much for me but bearable. I don't know how Tcl compares >> -- I just know that it's an alternative. >> >> So -- anyone have any direct experience with either of these, or with >> something else? We briefly considered Java, but it just looks entirely >> too big -- it would basically drive us to use Linux or some other >> "real" OS (even the little linuxes are too big for my tastes) -- I'd >> really rather just have a scripting engine that gets called whenever a >> script needs to run, and otherwise doesn't need much hand-holding from >> the application code. >> >> I'm looking for opinions, so fire away! << snip >> > Can you tolerate something as "crude" as a bastardized BASIC? I.e., > add "product specific" hooks to it to address some of the special needs > (displays, etc.) at a "native" level. A BASIC interpreter/compiler can > be really small. Oh, and -- we've booted the idea of BASIC around, too. As far as I'm concerned, the first letter or two of BASIC stands for BArf, and I'll have to write scripts for the thing. So it's not high on our list of preferred options. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@is.not.me.com> |
|---|---|
| Date | 2015-03-13 18:14 -0700 |
| Message-ID | <me020n$6qr$1@speranza.aioe.org> |
| In reply to | #20464 |
On 3/13/2015 5:06 PM, Tim Wescott wrote: >> Can you tolerate something as "crude" as a bastardized BASIC? I.e., >> add "product specific" hooks to it to address some of the special needs >> (displays, etc.) at a "native" level. A BASIC interpreter/compiler can >> be really small. > > Oh, and -- we've booted the idea of BASIC around, too. As far as I'm > concerned, the first letter or two of BASIC stands for BArf, and I'll have > to write scripts for the thing. So it's not high on our list of preferred > options. Presumably, your goal is to make life pleasant for the *customer*, not *yourself*! :> I offered BASIC as an option as you can write one in a few KB and is easily understood by "non-programmers". I've worked on instruments where (my) customer (e.g., chemist) was charged with scripting behaviors that *his* customers would blindly invoke (e.g., to determine if the hospital patient has Hep-C, HIV, etc.). So, lots riding on (my) customer "getting it right" as I'm not looking over his shoulder to verify he's considered every exception, boundary case, etc. (All I have to do is ensure the language is well-behaved and has no "gotchas" that are likely to trip someone up two-levels removed from me!
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2015-03-13 22:30 +0000 |
| Subject | Re: Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions? |
| Message-ID | <2yJMw.1101940$ls6.162089@fx16.am4> |
| In reply to | #20459 |
On 13/03/15 21:27, Tim Wescott wrote: > The title says most of it. > > I'm working on a project for which the customer wants a lot of flexibility > to customize a product. The existing "macro language" is ancient (ca > 1985), cryptic (it looks like machine language), limited, clunky, etc. > The customer is willing to change. > > I'm planning on having a chunk of serial flash (or an SD card) with a file > system on it (maybe FAT, maybe something home-rolled and primitive). > Scripts will be stored as text files, and read in as appropriate. > > Rather than just use some clunky cryptic and limited language that's > unique to the problem and to me (and charging my customer up the wazoo for > it), I'd like to use something that's open-source and available. > Something that uses modest resources is to be preferred -- my > understanding is that I can expect Lua to use about 100k of flash, which > is a bit much for me but bearable. I don't know how Tcl compares -- I > just know that it's an alternative. > > So -- anyone have any direct experience with either of these, or with > something else? We briefly considered Java, but it just looks entirely > too big -- it would basically drive us to use Linux or some other "real" > OS (even the little linuxes are too big for my tastes) -- I'd really > rather just have a scripting engine that gets called whenever a script > needs to run, and otherwise doesn't need much hand-holding from the > application code. > > I'm looking for opinions, so fire away! I wish everyone was as mature and rational! I'm personally sick and tired of scrotty little scripting languages that grey like Topsy until nobody, including their originators^H^H^H^H^H perpetrators, understood them anymore. I haven't used it myself, but Lua looks like it might be a good starting point, particularly since it is embeddable in/with C. ISTR there being an embeddable JavaScript (not Java!) interpreter, which might have the benefit of more familiar syntax.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-03-14 00:48 +0100 |
| Message-ID | <mdvsv9$am1$1@dont-email.me> |
| In reply to | #20459 |
On 13/03/15 22:27, Tim Wescott wrote: > The title says most of it. > > I'm working on a project for which the customer wants a lot of flexibility > to customize a product. The existing "macro language" is ancient (ca > 1985), cryptic (it looks like machine language), limited, clunky, etc. > The customer is willing to change. > > I'm planning on having a chunk of serial flash (or an SD card) with a file > system on it (maybe FAT, maybe something home-rolled and primitive). > Scripts will be stored as text files, and read in as appropriate. > > Rather than just use some clunky cryptic and limited language that's > unique to the problem and to me (and charging my customer up the wazoo for > it), I'd like to use something that's open-source and available. > Something that uses modest resources is to be preferred -- my > understanding is that I can expect Lua to use about 100k of flash, which > is a bit much for me but bearable. I don't know how Tcl compares -- I > just know that it's an alternative. > > So -- anyone have any direct experience with either of these, or with > something else? We briefly considered Java, but it just looks entirely > too big -- it would basically drive us to use Linux or some other "real" > OS (even the little linuxes are too big for my tastes) -- I'd really > rather just have a scripting engine that gets called whenever a script > needs to run, and otherwise doesn't need much hand-holding from the > application code. > > I'm looking for opinions, so fire away! > I used Lua in a project a number of years ago, and would use it again if I needed scripting. It has a few key advantages over TCL. It is a nicer language, it is quite easy to integrate in a C project (it consists of just a few C files), and it's easy to make your own functions callable from Lua. A disadvantage is that there is only one number type, which is floating point by default, but you can change that to integer if it suits you better (and it's certainly better than everything being a string, as it is in TCL).
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-03-13 19:45 -0700 |
| Message-ID | <87385870w8.fsf@nightsong.com> |
| In reply to | #20462 |
David Brown <david.brown@hesbynett.no> writes: > A disadvantage [of Lua] is that there is only one number type, which > is floating point by default, but you can change that to integer They finally added integers to Lua, as of version 5.3, released earlier this year.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-03-15 23:01 +0100 |
| Message-ID | <me4vdh$q6m$1@dont-email.me> |
| In reply to | #20470 |
On 14/03/15 03:45, Paul Rubin wrote: > David Brown <david.brown@hesbynett.no> writes: >> A disadvantage [of Lua] is that there is only one number type, which >> is floating point by default, but you can change that to integer > > They finally added integers to Lua, as of version 5.3, released earlier > this year. > Very nice! And I see that bitwise operators are now official, rather than just a common patch. That pretty much removes the two stumbling points Lua had as an embedded language for something like a Cortex M4.
[toc] | [prev] | [next] | [standalone]
| From | mroberds@att.net |
|---|---|
| Date | 2015-03-14 00:28 +0000 |
| Message-ID | <mdvvai$hle$1@dont-email.me> |
| In reply to | #20459 |
Tim Wescott <seemywebsite@myfooter.really> wrote:
> So -- anyone have any direct experience with either of these, or with
> something else?
I did a tiny amount of Tcl 10+ years ago, but that was on a Linux
desktop with GUI. For a while, sometimes Tcl was used as sort of the
Linux equivalent of Visual Basic - for when you wanted a simple GUI but
didn't want to spend weeks screwing around with X/(GTK|Qt)/C++. I've
never tried embedding Tcl in anything.
I *have* used embedded Lua more recently. Wireshark (a packet sniffer,
formerly called Ethereal) understands lots and lots of packet formats,
but if you've come up with your own weird thing, it just gives you a hex
dump of the payload. You can write your own packet parser in Lua and
Wireshark will run it on the payload for you. The basic application is
to make the packet more human-readable. You can also use it along with
Wireshark's native ability to trigger on or sort by certain data fields
to only log packets of interest.
The thing I found odd about the choice of Lua for this application was
that *it didn't have any bitwise operators*. You couldn't do stuff like
"if(packet[3] & 0x04) { /*...*/ }". I did a lot of multiply and divide
by 2, and tests like "if(packet[5] > 127)" to see if the high bit was
set. Also, IIRC, Lua's default numeric type was float.
This was a couple of years ago; maybe "full" Lua could do bitwise back
then and Wireshark was only implementing a subset, or maybe Lua couldn't
do it back then but can do it now.
Wireshark also had the option of writing a packet dissector in C, and
then compiling it into a library (.so or .dll depending on platform);
this was said to give you faster decoding. Most of the protocols I was
looking at sent packets at no more than a few dozen Hz; I think one of
them topped out around 1 KHz. The Lua scripts didn't seem to have any
problem doing "live" decodes on a new-in-2007 PC.
I know I've seen the option to embed a Lua interpreter in something more
"embedded", possibly U-Boot. Lua's Wikipedia page lists a lot of places
where it has been embedded.
I will give my standard advice: ship a few example scripts with the
product. You can assume that people know how to use arithmetic
operators and things like that, but the details of how to get data out
of and back into your hardware will be unique to your implementation.
I think Wireshark had a limited example in the manual, but since it's
popular, I was able to find additional examples online. Most
applications won't be able to count on that, though.
Matt Roberds
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@is.not.me.com> |
|---|---|
| Date | 2015-03-13 18:45 -0700 |
| Message-ID | <me03s5$9u2$1@speranza.aioe.org> |
| In reply to | #20465 |
Hi Matt,
On 3/13/2015 5:28 PM, mroberds@att.net wrote:
> Tim Wescott <seemywebsite@myfooter.really> wrote:
>> So -- anyone have any direct experience with either of these, or with
>> something else?
>
> I did a tiny amount of Tcl 10+ years ago, but that was on a Linux
> desktop with GUI. For a while, sometimes Tcl was used as sort of the
> Linux equivalent of Visual Basic - for when you wanted a simple GUI but
> didn't want to spend weeks screwing around with X/(GTK|Qt)/C++. I've
> never tried embedding Tcl in anything.
Are you sure you're not thinking of tk?
I looked at a bunch of OTS languages when I had to settle on a
scripting (i.e., "application") language. Many are far too cryptic
for casual users (I wanted to target "real programmers", hobbyists
and "homeowners" -- lots of competing criteria!).
Tcl has some features that are troublesome (e.g., upvar, uplevel) even
for "conventional" programmers. Imagine trying to explain them to
*casual* programmers/users.
> I *have* used embedded Lua more recently. Wireshark (a packet sniffer,
> formerly called Ethereal) understands lots and lots of packet formats,
> but if you've come up with your own weird thing, it just gives you a hex
> dump of the payload. You can write your own packet parser in Lua and
> Wireshark will run it on the payload for you. The basic application is
> to make the packet more human-readable. You can also use it along with
> Wireshark's native ability to trigger on or sort by certain data fields
> to only log packets of interest.
>
> The thing I found odd about the choice of Lua for this application was
> that *it didn't have any bitwise operators*. You couldn't do stuff like
> "if(packet[3] & 0x04) { /*...*/ }". I did a lot of multiply and divide
> by 2, and tests like "if(packet[5] > 127)" to see if the high bit was
> set. Also, IIRC, Lua's default numeric type was float.
I didn't like the fact that you could mix and match types without
anything alerting you to the fact that you're trying to do something
"wrong". E.g., if (5 == "5")...
Likewise, I thought the ability to perform multiple assignments
(with a *single* assignment operator) would cause problems. E.g.,
x, y = 1, 3 -- how would you "read that over the phone"?
"x and y get 1 and 3, respectively"? "x gets 1, y gets 3" (then
how is that *read* different from x=1 y=3)
Likewise, the potential for confusion when arguments are omitted
from function invocations. I.e., it doesn't do much to help
protect the programmer from "little (painful) mistakes":
"Oh, crap! Foo() takes *3* parameters!)
I've been surgically removing/rewriting features of Limbo (my
scripting choice) to try to ensure users can "get it right"
without scratching their heads to figure out what's wrong
with their code. Too many multiple character operators, etc.
> This was a couple of years ago; maybe "full" Lua could do bitwise back
> then and Wireshark was only implementing a subset, or maybe Lua couldn't
> do it back then but can do it now.
>
> Wireshark also had the option of writing a packet dissector in C, and
> then compiling it into a library (.so or .dll depending on platform);
> this was said to give you faster decoding. Most of the protocols I was
> looking at sent packets at no more than a few dozen Hz; I think one of
> them topped out around 1 KHz. The Lua scripts didn't seem to have any
> problem doing "live" decodes on a new-in-2007 PC.
>
> I know I've seen the option to embed a Lua interpreter in something more
> "embedded", possibly U-Boot. Lua's Wikipedia page lists a lot of places
> where it has been embedded.
>
> I will give my standard advice: ship a few example scripts with the
> product. You can assume that people know how to use arithmetic
> operators and things like that, but the details of how to get data out
> of and back into your hardware will be unique to your implementation.
> I think Wireshark had a limited example in the manual, but since it's
> popular, I was able to find additional examples online. Most
> applications won't be able to count on that, though.
>
> Matt Roberds
>
[toc] | [prev] | [next] | [standalone]
| From | Clifford Heath <no.spam@please.net> |
|---|---|
| Date | 2015-03-14 13:14 +1100 |
| Message-ID | <WPMMw.19349$bk5.2386@fx06.iad> |
| In reply to | #20467 |
On 14/03/15 12:45, Don Y wrote: > Are you sure you're not thinking of tk? tcl is the language, tk the toolkit - they're very close friends. > Likewise, I thought the ability to perform multiple assignments > (with a *single* assignment operator) would cause problems. > how is that *read* different from x=1 y=3) The only real use for multiple assignment is swapping values without using an explicit temporary: x, y = y, x > Likewise, the potential for confusion when arguments are omitted > from function invocations. I.e., it doesn't do much to help > protect the programmer from "little (painful) mistakes": > "Oh, crap! Foo() takes *3* parameters!) Calling a 3-argument function with 2 arguments should return a function that takes the remaining argument :) (I.e. currying) > I've been surgically removing/rewriting features of Limbo (my > scripting choice) Where can I read more about Limbo? Is this the language from Inferno? Hmm, that looks a lot like what I described in my other message :)
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@is.not.me.com> |
|---|---|
| Date | 2015-03-13 20:35 -0700 |
| Message-ID | <me0aad$l2j$1@speranza.aioe.org> |
| In reply to | #20469 |
Hi Clifford,
On 3/13/2015 7:14 PM, Clifford Heath wrote:
> On 14/03/15 12:45, Don Y wrote:
>> Are you sure you're not thinking of tk?
>
> tcl is the language, tk the toolkit - they're very close friends.
>
>> Likewise, I thought the ability to perform multiple assignments
>> (with a *single* assignment operator) would cause problems.
>> how is that *read* different from x=1 y=3)
>
> The only real use for multiple assignment is swapping values without using an
> explicit temporary:
> x, y = y, x
Yes -- saving a temporary. But, it's a feature that can easily be
abused (no direct consequences of doing so -- for the *abuser*).
Limbo suffers from this same problem:
x, y := 3;
sets *both* x and y to '3'. x, y = 2, 3 is an error.
To it's *credit*, the lua style of multiple assignment can be
accomplished using tuples:
(x, y) := (2, 3);
though tuples are far more useful for other things!
>> Likewise, the potential for confusion when arguments are omitted
>> from function invocations. I.e., it doesn't do much to help
>> protect the programmer from "little (painful) mistakes":
>> "Oh, crap! Foo() takes *3* parameters!)
>
> Calling a 3-argument function with 2 arguments should return a function that
> takes the remaining argument :) (I.e. currying)
>
>> I've been surgically removing/rewriting features of Limbo (my
>> scripting choice)
>
> Where can I read more about Limbo? Is this the language from Inferno?
> Hmm, that looks a lot like what I described in my other message :)
The vita nuova web site has has the two seminal papers on Limbo
(A Descent into Limbo; The Limbo Programming Language). I htink
there are two (?) texts that also address the language/"system"
(as Limbo is intimately tied up in Inferno... where the language
ends and the system begins can be debated).
But, it's more fleshy than a scripting language. E.g., contains
communication primitives *in* the language, seamlessly supports
RPC, multitasking, demand loadable modules, exceptions, GC, etc.
So, it's a good language to develop *real* applications in addition
to just hacking together simple little "basic" scripts.
The biggest problem is all the syntax that can easily intimidate
a casual user.
E.g.,
i = 1;
i := 1;
behave similarly but subtly different. A casual user might be
stressed to discover his problem boiled down to a missing/extra
colon! Or, "<-" vs. "->" vs. "=>". Niggly details. I, for
example, found it frustrating that you can't declare const lists.
Or even *initialize* a list in it's entirety!
(the current compiler leaves a lot to be desired in terms of
localizing errors)
FWIW, I think the current license terms are much more generous than
the *paid* license I acquired (change in their business model?)
So, you can download the environment -- BSD, Windows, OSX, Linux,
Slowaris, Plan 9 (of course) -- and play with it. At one point,
you could run the VM in a browser (not sure if that is still supported).
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2015-03-14 23:59 -0400 |
| Message-ID | <v7v9gah5k84p3vuuj4pj6g5qhqidh6r1jv@4ax.com> |
| In reply to | #20472 |
On Fri, 13 Mar 2015 20:35:54 -0700, Don Y <this@is.not.me.com> wrote: >Hi Clifford, > >On 3/13/2015 7:14 PM, Clifford Heath wrote: > >> The only real use for multiple assignment is swapping values without using an >> explicit temporary: >> x, y = y, x > >Yes -- saving a temporary. But, it's a feature that can easily be >abused (no direct consequences of doing so -- for the *abuser*). > >Limbo suffers from this same problem: > x, y := 3; >sets *both* x and y to '3'. Which is crazy. Looks like a bastard cross between Pascal's assignment and Modula's constant declaration syntax. > x, y = 2, 3 is an error. That's more reasonable. If you using := for assignment, then = is equal and multiple value equal doesn't make a whole lot of sense unless you're talking about ordered sets (tuples). But I would assume that Limbo has a syntax for constant tuples. >To it's *credit*, the lua style of multiple assignment can be >accomplished using tuples: > (x, y) := (2, 3); >though tuples are far more useful for other things! But a tuple semantically is different from multiple values. A tuple is a single container with multiple content - the container must be "opened" to get at its content whereas the individual values (typically) do not. Then there is the question of whether tuples can be frame allocated or whether they end up on the heap. And whether a tuple has O(1), O(N) or O(something else) access. Depending on the implementation, it might actually be faster to allocate a heap tuple than to return/set multiple values. But because it usually is slower to unpack the tuple, that may eat up any saving from using it in the first place. George
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@is.not.me.com> |
|---|---|
| Date | 2015-03-14 22:30 -0700 |
| Message-ID | <me35dd$onh$1@speranza.aioe.org> |
| In reply to | #20491 |
On 3/14/2015 8:59 PM, George Neuner wrote:
> On Fri, 13 Mar 2015 20:35:54 -0700, Don Y <this@is.not.me.com> wrote:
>> On 3/13/2015 7:14 PM, Clifford Heath wrote:
>>
>>> The only real use for multiple assignment is swapping values without using an
>>> explicit temporary:
>>> x, y = y, x
>>
>> Yes -- saving a temporary. But, it's a feature that can easily be
>> abused (no direct consequences of doing so -- for the *abuser*).
>>
>> Limbo suffers from this same problem:
>> x, y := 3;
>> sets *both* x and y to '3'.
>
> Which is crazy. Looks like a bastard cross between Pascal's
> assignment and Modula's constant declaration syntax.
It's effectively,
x: int;
y: int;
x = 3;
y = 3;
Or,
x, y: int;
x = y = 3;
>> x, y = 2, 3 is an error.
>
> That's more reasonable. If you using := for assignment, then = is
':=' declares and defines; ':' declares while '=' defines
So,
x, y = 3;
> equal and multiple value equal doesn't make a whole lot of sense
> unless you're talking about ordered sets (tuples). But I would assume
> that Limbo has a syntax for constant tuples.
>
>> To it's *credit*, the lua style of multiple assignment can be
>> accomplished using tuples:
>> (x, y) := (2, 3);
>> though tuples are far more useful for other things!
>
> But a tuple semantically is different from multiple values. A tuple
> is a single container with multiple content - the container must be
> "opened" to get at its content whereas the individual values
> (typically) do not.
That's not required in limbo. E.g., it is common for a function to
return a tuple: one member being a flag (success/fail) with the other(s)
being the expected result(s).
E.g., you could create a function that parses a (unsorted) list of values
comparing each to a "given" and returns:
- the count of values below the given value
- the count of values above the given value
- the count of values *at* the given value
- a (sorted?) list of all (unique) values below the given value
- a sorted list of all the unique values above the given value
- a summary code (like an error code: LIST_EMPTY, SUCCESS, etc.)
[Note that the number of entries in each of these lists may be less
than the *counts* returned as duplicates will be elided]
In the following, assume the "values" are strings:
check_list(
given: string, // what we seek
candidates: list of string // where it is sought
) :
(int, // count below
int, // count at
int, // count above
list of string, // sorted strings below sought
list of string, // sorted strings above sought
int // result code
)
it could then be invoked as:
(below, at, above, before, after, result) := check_list("Penny", names);
Use of the ':=' operator saves me the effort of declaring each of the types
of the members of that tuple. This is sort of an "anonymous" tuple (the
function could have returned it's values to a variable of the appropriate
tuple type)
Then, I could say:
if (below < above) {
sys->print("Of the " + string (len names) + "names examined, far"
+ " more names preceded the name of interest than followed."
+ " There were %d different names preceding, lexically,"
+ " and %d names following.", len before, len after);
...
[Highly contrived example]
Assuming these are the only return values used from that function
invocation, a smarter way of invoking it would have been:
(below, nil, above, before, after, nil) := check_list("george", names);
which makes it obvious which values are not used.
> Then there is the question of whether tuples can be frame allocated or
> whether they end up on the heap. And whether a tuple has O(1), O(N) or
> O(something else) access.
>
> Depending on the implementation, it might actually be faster to
> allocate a heap tuple than to return/set multiple values. But because
> it usually is slower to unpack the tuple, that may eat up any saving
> from using it in the first place.
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2015-03-15 21:44 -0400 |
| Message-ID | <n9ccgal3s6egurb9c3lkopts5l3pp2hea9@4ax.com> |
| In reply to | #20494 |
On Sat, 14 Mar 2015 22:30:30 -0700, Don Y <this@is.not.me.com> wrote: >On 3/14/2015 8:59 PM, George Neuner wrote: > >> But a tuple semantically is different from multiple values. A tuple >> is a single container with multiple content - the container must be >> "opened" to get at its content whereas the individual values >> (typically) do not. > >That's not required in limbo. E.g., it is common for a function to >return a tuple: one member being a flag (success/fail) with the other(s) >being the expected result(s). And how do you access those values in the tuple - surely it can't be the same as values not in the tuple. Multiple-value return is more complex than single-value return. Many languages allow functions to return a container type to preserve the (relative) simplicity of the single-value return. Ansi C does this with structs. I don't know what Limbo does, but tuple using languages typically allocate the tuple and its contents separately and then return a reference to the tuple. Which goes back to what I said about the cost of accessing the values. George
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@is.not.me.com> |
|---|---|
| Date | 2015-03-15 20:09 -0700 |
| Message-ID | <me5hh0$sb8$1@speranza.aioe.org> |
| In reply to | #20500 |
On 3/15/2015 6:44 PM, George Neuner wrote:
> On Sat, 14 Mar 2015 22:30:30 -0700, Don Y <this@is.not.me.com> wrote:
>
>> On 3/14/2015 8:59 PM, George Neuner wrote:
>>
>>> But a tuple semantically is different from multiple values. A tuple
>>> is a single container with multiple content - the container must be
>>> "opened" to get at its content whereas the individual values
>>> (typically) do not.
>>
>> That's not required in limbo. E.g., it is common for a function to
>> return a tuple: one member being a flag (success/fail) with the other(s)
>> being the expected result(s).
>
> And how do you access those values in the tuple - surely it can't be
> the same as values not in the tuple.
As in the example I posted. You *think* of tuples as structs. But,
they don't really exist in an abstract sense. I.e., they only
exist when you are accessing them -- as (...).
E.g., you can have a function return a (string, int). Another similar
function can also return a (string, int). You don't consider the
results of these two functions to be "the same type" -- in the sense
that (in C) you would create a typedef struct that *both* would use.
You don't reference the "members" of a tuple by "names/identifiers".
Rather, *positionally*, via a "(...) = <tuple_type>" assignment.
One of the annoyances of Limbo is exactly that. You end up with code
stanzas like:
(name, count) := function_that_returns_a_string_and_an_int(...);
...
(name, count) := function_that_returns_a_string_and_an_int(...);
The second invocation screws you because you've already got a
"name" and "count" in the current scope. So, you end up
rewriting:
(name, count) := function_that_returns_a_string_and_an_int(...);
...
(name, count) = function_that_returns_a_string_and_an_int(...);
or, declaring name and count "up top" somewhere and then:
(name, count) = function_that_returns_a_string_and_an_int(...);
...
(name, count) = function_that_returns_a_string_and_an_int(...);
> Multiple-value return is more complex than single-value return. Many
> languages allow functions to return a container type to preserve the
> (relative) simplicity of the single-value return. Ansi C does this
> with structs.
Yes. The struct analogy in Limbo is the adt (Abstract Data Type)
which is often a (user-)named type.
Modules (which are a formal type) are essentially adt's -- the
data and function members thereof accessed through pointers to
the underlying module: "module->member" notation (where
"module" is a pointer to a loaded "Module")
> I don't know what Limbo does, but tuple using languages typically
> allocate the tuple and its contents separately and then return a
> reference to the tuple. Which goes back to what I said about the cost
> of accessing the values.
Limbo avoids this by letting (forcing!) you to declare the variables
into which the result(s) get stuffed. So, it's just syntactic sugar, of
a sort.
I.e., in the first (":=") example, name and count are declared (created)
in the current stack frame so there's a place for these "return values"
to get stuffed. In the second ("=") example, the variables were previously
declared (and accessible in this scope) so the same idea applies.
There's no "hidden" allocation/GC required (beyond that of cleaning
up the stack frame when the block exists).
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2015-03-14 23:59 -0400 |
| Message-ID | <o1u9ga981b3q7iarhqs7thhbvqani6hr18@4ax.com> |
| In reply to | #20469 |
On Sat, 14 Mar 2015 13:14:12 +1100, Clifford Heath <no.spam@please.net> wrote: >The only real use for multiple assignment is swapping values without >using an explicit temporary: >x, y = y, x No, there are other uses - the most common to return both a result and error/status from a function. However, multiple assignment - or equivalently, multiple value return - too often is abused by allowing some of the values to be elided. There are times when all values aren't interesting, but IMO there should be a syntactic placeholder that is not assigned to. >> Likewise, the potential for confusion when arguments are omitted >> from function invocations. I.e., it doesn't do much to help >> protect the programmer from "little (painful) mistakes": >> "Oh, crap! Foo() takes *3* parameters!) > >Calling a 3-argument function with 2 arguments should return a function >that takes the remaining argument :) (I.e. currying) Remember which forum you're in 8-) Currying creates closures and *may* additionally require GC. Many high level language features don't mix well with small devices. George
[toc] | [prev] | [next] | [standalone]
Page 1 of 4 [1] 2 3 4 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web