I noticed that Codea does not have support for the lua io.read() function to accept input and store it as a variable. Are there any ways to do something similar in Codea? Any help would be greatly appreciated.
Do you mean input from the keyboard? There currently is no way to get keyboard input in Codea.
For example ask user for name, have them input it and store it as variable such as “Name” to be used later. This isn’t currently possible?
No, but that is definitely something we can add! The initial API is pretty minimal, mostly because we didn’t know what people would want. Thanks for bringing this up, and we will look at how we can integrate keyboard input.
Cool. I think it would be a great feature to have so that users can add a personal touch to apps by getting some input from user. Any idea when this might become available?
We can’t give dates for when we might implement feature requests sorry. We are working as fast as we can to fix bugs and get the name change through. After that we will release a roadmap with future feature plans.
Ok. I’m looking forward to many future updates 
Any news on this feature being implemented?
You can add it as a feature request on the issue tracker at https://bitbucket.org/TwoLivesLeft/codea/issues
That way it will be in the list, and you will get notifications on when we comment on the issue, or change its status.
+1 for this feature. Just got it posted on issue tracker as well.
Agreed. +1 from me too on accepting input. I have a legion of students who will want it.
So basically this would be a button in the side panel that brings up the keyboard, pressing keys on the keyboard calls a keyboard(key) callback in your code. There would also be API functions to showKeyboard() and hideKeyboard(). This is what you are all thinking?
@simeon: No, I didn’t think that complicated. 
input() function is a common Lua function to accept text from users. What I was thinking is… everytime Codea found an input() call, it opens up an input box, automatically show up the standard virtual keyboard, then save the given text into a variable to processed by the rest of the code.
Here’s a pseudocode for the usage:
name = input() print(name)
This input() function shouldn’t be mixed up with keyboard API which obviously is more complex than that. Keyboard API should be able to detect key event (up/down), input filtering, multikey event, manage virtual keyboard appearance, etc. This keyboard API should become another separated discussion. 
But that would be a blocking call. It would pause your app from running while waiting for the result from input()
Yes. Just like the old days read() function in Pascal.
I was thinking pausing the code as well, but a keyboard(key) event is more flexible and more in line with touched(touch).
Yes, keyboard API is much more flexible but it requires more control. Sometimes we, especially beginners, just need to get input with ease. That’s when the input() plays its role. And it’s more in line with text based program (also had been requested as well on other discussion) rather than graphical program.
Simeon - you basically hit it on the nose. Show/hide keyboard from code, and being able to read keystrokes. Bonus points if you can read keystrokes without the keyboard being up (that’s for bluetooth keyboards and the icade). If we get that far, wrapping it up in a nice input box is easy peasy.
Bee, I’m working on a “console” - a class to use the screen (or an overlay on the screen, really) as a text console. You’d be able to print to it, and it would scroll like you’d expect, and with a keyboard be able to get input - so something like a text adventure would be easy (or the I/O would be, at least). It’s maybe half done - without keyboard input, it’s not nearly as exciting as it could be. I have a keyboard semi-working in my font stuff, but it’s crude and unpleasant still - it might be ok for “type your initials”, but not for real typing.
Here’s a sneak preview: https://twitter.com/#!/bortels/status/144259697216720897/photo/1
Other than including the tab and using “c = Console()” in the setup(), you just do ‘c:log(“Hello World”)’ and it handles scrolling and wrap and so on. (or it will - scrolling is there, wrap is not).
How about designing it so it can run in a non-blocking thread with callbacks? I would love to see more parallel thread options in general, to support some more sophisticated programming models.
I would assume any keyboard activity would be handled like draw() - ie. you’d make a “function keyevent(e)” and e would be the event - “k down” or “k up” or such. So it’d get called when keys happened, not blocking. A blocking interface doesn’t fit well with Codea’s draw() oriented event loop.