Re: [fonc] Magic Ink and Killing Math
On 3/8/2012 9:32 PM, David Barbour wrote:
Bret Victor's work came to my attention due to a recent video,
Inventing on Principle
http://vimeo.com/36579366
If you haven't seen this video, watch it. It's especially appropriate
for the FoNC audience.
although I don't normally much agree with the concept of principle,
most of what was shown there was fairly interesting.
kind of makes some of my efforts (involving interaction with things via
typing code fragments into a console) seem fairly weak... OTOH, at the
moment, I am not entirely sure how such a thing would be implemented
either (very customized JS interpreter? ...).
it also much better addresses the problem of how do I easily get an
object handle for that thing right there?, which is an unsolved issue
in my case (one can directly manipulate things in the scene via script
fragments entered as console commands, provided they can get a reference
to the entity, which is often a much harder problem).
timeliness of feedback is something I can sort of relate to, as I tend
to invest a lot more effort in things I can do fairly quickly and test,
than in things which may take many hours or days before I see much of
anything (and is partly a reason I invested so much effort into my
scripting VM, rather than simply just write everything in C or C++ and
call it good enough, even despite the fair amount of code that is
written this way).
most notable thing I did recently (besides some fiddling with getting a
new JIT written), was adding a syntax for block-strings. I used [[ ...
]] rather than triple-quotes (like in Python), mostly as this syntax is
more friendly to nesting, and is also fairly unlikely to appear by
accident, and couldn't come up with much obviously better at the
moment, {{ ... }} was another considered option (but is IIRC already
used for something), as was the option of just using triple-quote (would
work, but isn't readily nestable).
this was itself a result of a quick thing which came up while writing
about something else:
how to deal with the problem of easily allowing user-defined syntax in a
language without the (IMO, relatively nasty) feature of allowing
context-dependent syntax in a parser?...
most obvious solution: some way to easily create large string literals,
which could then be fed into a user-defined parser / eval. then one can
partly sidestep the matter of syntax within a syntax. granted, yes, it
is a cheap hack...
Anyhow, since then I've been perusing Bret Victor's other works at:
http://worrydream.com
Which, unfortunately, renders painfully slowly in my Chrome browser
and relatively modern desktop machine. But sludging through the first
page to reach content has been rewarding.
One excellent article is Magic Ink:
http://worrydream.com/MagicInk/
In this article, Victor asks `What is Software?` and makes a case that
`interaction` should be a resource of last resort, that what we often
need to focus on is presenting context-relevant information and
graphics design, ways to put lots of information in a small space in a
non-distracting way.
And yet another article suggests that we Kill Math:
http://worrydream.com/KillMath/
Which focuses on using more concrete and graphical representations to
teach concepts and perform computations. Alan Kay's work teaching
children (Doing With Images Makes Symbols) seems to be relevant here,
and receives a quote.
Anyhow, I think there's a lot here everyone, if you haven't seen it
all before.
nifty...
(although, for me, at the moment, it is after 2AM, I am needing to
sleep...).
Regards,
Dave
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Magic Ink and Killing Math
most notable thing I did recently (besides some fiddling with getting a new
JIT written), was adding a syntax for block-strings. I used [[ ... ]]
rather than triple-quotes (like in Python), mostly as this syntax is more
friendly to nesting, and is also fairly unlikely to appear by accident, and
couldn't come up with much obviously better at the moment, {{ ... }}
was another considered option (but is IIRC already used for something), as
was the option of just using triple-quote (would work, but isn't readily
nestable).
You should have a look at Lua's long string syntax if you haven't already:
[[ my
long
string]]
You can nest by matching the number of '=' between the brackets:
[===[
a
long
string [=[ with a long string inside it ]=]
xx
]===]
wes
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Magic Ink and Killing Math
On Sat, Mar 10, 2012 at 01:21:42AM -0800, Wesley Smith wrote:
most notable thing I did recently (besides some fiddling with getting a new
JIT written), was adding a syntax for block-strings. I used [[ ... ]]
rather than triple-quotes (like in Python), mostly as this syntax is more
friendly to nesting, and is also fairly unlikely to appear by accident, and
couldn't come up with much obviously better at the moment, {{ ... }}
was another considered option (but is IIRC already used for something), as
was the option of just using triple-quote (would work, but isn't readily
nestable).
You should have a look at Lua's long string syntax if you haven't already:
Better to be consistent with rest of scripting languages(bash,ruby,perl,python)
and use heredocs.
--
Your packets were eaten by the terminator
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
[fonc] Block-Strings / Heredocs (Re: Magic Ink and Killing Math)
On 3/10/2012 2:21 AM, Wesley Smith wrote:
most notable thing I did recently (besides some fiddling with getting a new
JIT written), was adding a syntax for block-strings. I used[[ ... ]]
rather than triple-quotes (like in Python), mostly as this syntax is more
friendly to nesting, and is also fairly unlikely to appear by accident, and
couldn't come up with much obviously better at the moment, {{ ... }}
was another considered option (but is IIRC already used for something), as
was the option of just using triple-quote (would work, but isn't readily
nestable).
You should have a look at Lua's long string syntax if you haven't already:
[[ my
long
string]]
this was briefly considered, but would have a much higher risk of clashes.
consider someone wants to type a nested array:
[[1, 2, 3], [4, 5, 6], [7, 8, 9]]
which is not so good if this array is (randomly) parsed as a string.
preferable is to try to avoid syntax which is likely to appear by
chance, as then programmers have to use extra caution to avoid any
magic sigils which might have unintended behaviors, but can pop up
randomly as a result of typing code using only more basic constructions
(I try to avoid this much as I do ambiguities in general, and is partly
also why, IMO, the common AS, T syntax for templates/generics is a
bit nasty).
the syntax:
[[ ... ]]
was chosen as it had little chance of clashing with other valid syntax
(apart from, potentially, the CDATA end marker for XML, which at present
would need to be escaped if using this syntax for globs of XML).
it is possible, as the language does include unary and
operators, which could, conceivably, be applied to a nested array. this
is, however, rather unlikely, and could be fixed easily enough with a space.
as-is, they have an even-nesting rule.
WRT uneven-nesting, they can be escaped via '\' (don't really like, as
it leaves the character as magic...).
[[
this string has an embedded \]]...
but this is ok.
]]
OTOH (other remote possibilities):
{ ... }
was already used for insert-here expressions in XML literals:
foo{generateSomeNode()}/foo
(...) or ((...)) just wouldn't work (high chance of collision).
#(...), #[...], and #{...} are already in use (tuple, float vector or
matrix, and list).
example:
vector: #[0, 0, 0]
quaternion: #[0, 0, 0, 1]Q
matrix: #[[1, 0, 0] [0, 1, 0] [0, 0, 1]]
list: #{#foo, 2, 3; #v}
note: (...) parens, [...] array, {...} dictionary/object (example: {a:
3, y: 4}).
@(...), @[...], and @{...} are still technically available.
also possible:
/[...]/ , /[[...]]/
would be passable mostly only as /.../ is already used for regex
syntax (inherited from JS...).
hmm:
? ... ?
? ... ?
(available, currently syntactically invalid).
likewise:
\ ... \, ...
| ... |
...
so, the issue is mostly lacking sufficient numbers of available (good)
brace types.
in a few other cases, this lack has been addressed via the use of
keywords and type-suffixes.
but, a keyword would be lame for a string, and a suffix wouldn't work.
You can nest by matching the number of '=' between the brackets:
[===[
a
long
string [=[ with a long string inside it ]=]
xx
]===]
this would be possible, as otherwise this syntax would not be
syntactically valid in the language.
[=[...]=]
would be at least possible.
not that I particularly like this syntax though...
(inlined):
On 3/10/2012 2:43 AM, Ondřej Bílka wrote:
On Sat, Mar 10, 2012 at 01:21:42AM -0800, Wesley Smith wrote:
You should have a look at Lua's long string syntax if you haven't
already:
Better to be consistent with rest of scripting languages(bash,ruby,perl,python)
and use heredocs.
blarg...
heredoc syntax is nasty IMO...
I deliberately didn't use heredocs.
if I did, I would probably use the syntax:
#END; ... END
or similar...
Python uses triple-quotes, which I had also considered (just, they
couldn't nest):
lots of stuff...
over multiple lines...
this would mean:
[[
lots of stuff...
over multiple lines...
]]
possibly also with the Python syntax:
...
or such...
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
