Dyalog '14 - Videos week 1
Forum rules
This forum is for listing forthcoming meetings, conferences and any other sort of APL-related events.
This forum is for listing forthcoming meetings, conferences and any other sort of APL-related events.
4 posts
• Page 1 of 1
Dyalog '14 - Videos week 1
An exciting week – the first videos from our user meeting are now live!
Go to http://www.dyalog.com/dyalog_14/index.html to read about Dyalog '14 and follow the links to the videos.
• "Welcome" is the first of the presentations from Dyalog '14. Gitte opens the user meeting and introduces the new members of Team Dyalog before performing a brief retrospective of the achievements of the last decade. http://video.dyalog.com/Dyalog14/?v=j-uQjEPPGPo
• Morten's "Technical Road Map" concentrates on the direction that Dyalog is moving in, with particular emphasis on the tools and interfaces that are becoming increasingly important. He summarises the new functionality in Dyalog version 14.0 (released 2014Q2) and introduces the areas that will be concentrated on in coming releases. http://video.dyalog.com/Dyalog14/?v=rRRyDWaU1fA
• In "Gestures and Desktop Scaling in Windows 8", John tackles the issue of desktop scaling that results from ever-increasing screen resolutions and dpi. He presents the ScaledPixel and RealPixel co-ordinate types proposed for version 14.1 as an alternative to the default bitmap stretching performed by Microsoft Windows. Also proposed for version 14.1 is support for gestures, and John demonstrates three of the gesture events (zoom, rotate and pan) that the interpreter will handle. http://video.dyalog.com/Dyalog14/?v=0y5-ophsdGA
We'll be releasing new Dyalog '14 presentation videos every Friday for the next few months. If you have any requests for specific videos that you’d like to see sooner rather than later then please let us know at usermeeting@dyalog.com and we'll see what we can do.
Go to http://www.dyalog.com/dyalog_14/index.html to read about Dyalog '14 and follow the links to the videos.
• "Welcome" is the first of the presentations from Dyalog '14. Gitte opens the user meeting and introduces the new members of Team Dyalog before performing a brief retrospective of the achievements of the last decade. http://video.dyalog.com/Dyalog14/?v=j-uQjEPPGPo
• Morten's "Technical Road Map" concentrates on the direction that Dyalog is moving in, with particular emphasis on the tools and interfaces that are becoming increasingly important. He summarises the new functionality in Dyalog version 14.0 (released 2014Q2) and introduces the areas that will be concentrated on in coming releases. http://video.dyalog.com/Dyalog14/?v=rRRyDWaU1fA
• In "Gestures and Desktop Scaling in Windows 8", John tackles the issue of desktop scaling that results from ever-increasing screen resolutions and dpi. He presents the ScaledPixel and RealPixel co-ordinate types proposed for version 14.1 as an alternative to the default bitmap stretching performed by Microsoft Windows. Also proposed for version 14.1 is support for gestures, and John demonstrates three of the gesture events (zoom, rotate and pan) that the interpreter will handle. http://video.dyalog.com/Dyalog14/?v=0y5-ophsdGA
We'll be releasing new Dyalog '14 presentation videos every Friday for the next few months. If you have any requests for specific videos that you’d like to see sooner rather than later then please let us know at usermeeting@dyalog.com and we'll see what we can do.
- Karen|Dyalog
- Posts: 172
- Joined: Thu Nov 26, 2009 11:35 am
Re: Dyalog '14 - Videos week 1
In Technical Road Map http://video.dyalog.com/Dyalog14/?v=rRRyDWaU1fA some 25 minutes in, Morten said:
The central tenet (my emphasis) is perfectly true but there would appear to be no justification to base it on or even to mention the role of scripts in this.
I won't reproduce any of them here but I, probably along with several or many others, have come up with at least four different schemes for doing just this in functions.
I don't use scripts or at least I avoid them as much as I can and believe that they:
The requirement for an array notation has been there since Ken Iverson, with all his wisdom, omitted to allow for the direct definition of data in more than one dimension in APL syntax. But the possibility didn't really present itself until 1997 with the release of Dyalog 8.1 that included dfns for the first time. Here we had a new syntax that permitted a pair of braces "{ }" to span a number of line-ends within a function rather than brackets "[ ]" and parentheses "( )" both of which were restricted to a single line. If we could encompass several lines then we could include the unambiguous display of a multidimensional array that could be evaluated during the tokenisation of the containing function and obliterate the need to store global "variables" along with the code.
This did not precede the advent of control structures but it certainly preceded that of scripts.
I finally submitted two of my proposals to Dyalog in April of last year. One of them was indeed for a new control structure ":Array ⋄ ... ⋄ :EndArray". Even this could have been embedded equally within a tradfn as a script but more importantly the other was a new syntax construct that completely and unambiguously utilises brackets "[ ]" to delimit an assignable and/or immediately useable, multi-line, array definition that would be just as much at home in a dfn.
No sign of scripts anywhere.
Phil
And I think the emphasis on using scripts to store source code means that it's probably time for us to come up with a notation for constants in the language so that in your script you can declare matrices and so on in a nice readable fashion.
The central tenet (my emphasis) is perfectly true but there would appear to be no justification to base it on or even to mention the role of scripts in this.
I won't reproduce any of them here but I, probably along with several or many others, have come up with at least four different schemes for doing just this in functions.
I don't use scripts or at least I avoid them as much as I can and believe that they:
- hinder rather than aid the co-operative development, storage and retrieval of shared code;
- prevent the simultaneous refactoring of a number of related functions in a project;
- discourage code reuse and the D.R.Y (don't repeat yourself) principle;
The requirement for an array notation has been there since Ken Iverson, with all his wisdom, omitted to allow for the direct definition of data in more than one dimension in APL syntax. But the possibility didn't really present itself until 1997 with the release of Dyalog 8.1 that included dfns for the first time. Here we had a new syntax that permitted a pair of braces "{ }" to span a number of line-ends within a function rather than brackets "[ ]" and parentheses "( )" both of which were restricted to a single line. If we could encompass several lines then we could include the unambiguous display of a multidimensional array that could be evaluated during the tokenisation of the containing function and obliterate the need to store global "variables" along with the code.
This did not precede the advent of control structures but it certainly preceded that of scripts.
I finally submitted two of my proposals to Dyalog in April of last year. One of them was indeed for a new control structure ":Array ⋄ ... ⋄ :EndArray". Even this could have been embedded equally within a tradfn as a script but more importantly the other was a new syntax construct that completely and unambiguously utilises brackets "[ ]" to delimit an assignable and/or immediately useable, multi-line, array definition that would be just as much at home in a dfn.
No sign of scripts anywhere.
Phil
-
Phil Last - Posts: 628
- Joined: Thu Jun 18, 2009 6:29 pm
- Location: Wessex
Re: Dyalog '14 - Videos week 1
The main point I was trying to make was that, once you start using scripts to represent the source code for your application, rather than storing it in a workspace or on component files, you don't HAVE a way to represent constants or other arrays that define the application (as opposed to the data that an application manipulates). Thus, scripts rather force the issue.
An array representation that can be embedded within functions would clearly also be useful, and I think we should aim to allow that. Thanks for the proposals that you have submitted, they were archived and will be dug up when we start this work in earnest (expect a call).
Having said that, I think it would be a good idea to come up with a syntax that does not NEED to be embedded within a function. And if you don't have a function as a container, you need somewhere else to store it. Which brings us back to scripts.
An array representation that can be embedded within functions would clearly also be useful, and I think we should aim to allow that. Thanks for the proposals that you have submitted, they were archived and will be dug up when we start this work in earnest (expect a call).
Having said that, I think it would be a good idea to come up with a syntax that does not NEED to be embedded within a function. And if you don't have a function as a container, you need somewhere else to store it. Which brings us back to scripts.
-
Morten|Dyalog - Posts: 459
- Joined: Tue Sep 09, 2008 3:52 pm
Re: Dyalog '14 - Videos week 1
I assume you mean by this something of the nature of
For those who think the control structure paradigm was a productive and overall useful addition to APL this will be fine. You could embed it in scripts or in tradfns. No reason why not. Just as there's no reason apart from lack of imagination why you can't embed a :Namespace or a :Class defn. inside a tradfn.
So yes, if you think the above is as useful or comprehensible as
But you do realise that once this is implemented there will no longer be the slightest excuse to keep any residual difference between scripted and non-scripted namespaces. ⎕SRC will be for any namespace exactly what ⎕CR/⎕NR/⎕VR are for any defined function, merely a method to serialise it for storage or transmission
Many thanks in advance.
Phil
...possibly including other keywords for increased rank, depth &c.
:Array thisArray
13 75 45 53 21 4
7 67 93 38 51 83
...
:EndArray
For those who think the control structure paradigm was a productive and overall useful addition to APL this will be fine. You could embed it in scripts or in tradfns. No reason why not. Just as there's no reason apart from lack of imagination why you can't embed a :Namespace or a :Class defn. inside a tradfn.
So yes, if you think the above is as useful or comprehensible as
...then let's have them both.
thisArray ← [
13 75 45 53 21 4
67 67 93 38 51 83
...
]
But you do realise that once this is implemented there will no longer be the slightest excuse to keep any residual difference between scripted and non-scripted namespaces. ⎕SRC will be for any namespace exactly what ⎕CR/⎕NR/⎕VR are for any defined function, merely a method to serialise it for storage or transmission
thisSpace←⎕NS''while ⎕FIX will be able to create a container namespace with individually editable functions restoring all the benefits for the developer that scripts as development medium take away; and ⎕CR/⎕NR/⎕VR will naturally extend to any array as well as defined function.
thisSpace.thisArray←?2 6⍴10
thisSpace.(thisFn←{⍺→⊢ ⋄ ⍺⊣⍵})
⍪⎕SRC thisSpace
:Namespace thisSpace
:Array thisArray
5 0 6 4 7 9
7 2 0 7 3 6
:EndArray
thisFn←{⍺←⊢ ⋄ ⍺⊣⍵}
:EndNamespace
Many thanks in advance.
Phil
-
Phil Last - Posts: 628
- Joined: Thu Jun 18, 2009 6:29 pm
- Location: Wessex
4 posts
• Page 1 of 1
Who is online
Users browsing this forum: No registered users and 1 guest
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group